Subject: Re: [boost] [test] Trunk broken: What happened to test_exec_monitor?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-10-05 07:04:04
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Dave
> Sent: Tuesday, October 04, 2011 8:16 PM
> To: boost_at_[hidden]
> 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
> be able to use that development model, but everyone else expects library authors with boost
> 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,
> of the actual inconvenience to others is irrelevant; they're going to be upset because they've
> 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
> 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
> development model and your customers won't change their expectations, the only solution for them
> 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 A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk