Re: [boost] [test] Trunk broken: What happened to test_exec_monitor?

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
> Abrahams
> 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
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
[phone]  07714330204
pbristow_at_[hidden]