-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dave Abrahams Sent: Tuesday, October 04, 2011 8:16 PM To: boost@lists.boost.org Subject: Re: [boost] [test] Trunk broken: What happened to test_exec_monitor?
on Tue Oct 04 2011, Gennadiy Rozental <rogeeff-AT-gmail.com> wrote:
Dave Abrahams <dave <at> boostpro.com> writes:
It is. But as you've seen over the years, it causes an unworkable amount of upset and alarm when large numbers of failures appear on the trunk all at once, and people who would otherwise be dealing with release issues now have trunk issues to worry about.
That's why I always advocated independent library development.
We all (well, many of us) want that. We're not there yet.
Sometimes I do break trunk due to missed commit or compiler differences, but these quickly resolved. I need some way to make sure my changes are working.
But that can't have been the case here, can it? Surely if you'd run the whole boost regression suite on your local machine before and after your changes, you'd have seen the differences, no?
No, I can't. I have limited time I can spend working on boost development. I cannot wait hours for full regression test to finish even once, not mention twice. I expect regression test system to deal with this. I resolving issues once I observe them online.
So you do have a philosophical disagreement with the expectations of the group. You think you ought to be able to use that development model, but everyone else expects library authors with boost dependents to test the dependents before they commit changes.
So every time you do this and things break on trunk, it causes a big kerfuffle. At this point,
the magnitude
of the actual inconvenience to others is irrelevant; they're going to be upset because they've been through this with you over and over.
Do you really think that after 5 years of waiting to remove this facility, kicking off a boost-wide test and looking for problems would have cost you more time than it's costing you to deal with all this fallout from the problems you've caused?
I do run my own regression tests and they pass.
The fact is that your (Boost) customers aren't happy when you develop this way. If you won't change your development model and your customers won't change their expectations, the only solution for them is to stop using Boost.Test... which I did long ago, for this very reason.
I'd be reluctant to stop using Boost.Test - it does what it says on the tin. And I think there are very big advantages for every Boost library to use it too - it's the devil that we know. But this makes it a special case that every library will be dependent on it, so deprecation needs to have a really good reason, and be really, really well tested. I've been annoyed to have to change hundreds of projects to accommodate the changes you want to make. Ok - the changes are small, but "if it ain't broke, don't fix it". Is there a really, really, really good case for making these changes? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com