Subject: Re: [boost] [test] Trunk broken: What happened to test_exec_monitor?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-04 13:13:28
on Mon Oct 03 2011, Gennadiy Rozental <rogeeff-AT-gmail.com> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>> This is so obvious, and things like this have happened so many times,
>> that I'm amazed they're still happening.
> Not sure what you refer to. I did not make any major changes for many many years.
Call it my perception then, if you like. I don't have time right now to
dig through history to prove it quantitatively. You have a reputation
for committing changes that cause pervasive test failures in other
libraries, and for doing so close to a release when it's a more alarming
and inconvenient than necessary. I know we've had situations like this
on multiple occasions. I would like to think that the reactions you've
received over the years would make you more cautious.
>> Gennadiy, what do we have to do to get you to take appropriate care with
>> respect to your dependent libraries' test results?
>> Is there some philosophical disagreement with
>> the expectations of the group that you just can't bring yourself to meet
> Aside from the test_exec_monitor removal (which I'll reinstate for now) is there
> any other way in current setup for me to check in and test my changes?
How about at least testing them before you check them in? Another thing
you can do is test them on as many compilers as you can possibly get
your hands on. That's what I do.
> There is always a chance that due to compiler differences trunk will
> be broken for short period of time.
Yes, but that isn't the case here, is it? I'm sure all compilers are
pretty much equally unforgiving of the removal of a component that's in
> As you said - this is so obvious. The only reason we talking about
> this is because any changes I made bound to have higher exposure (in
> comparison with other boost libraries).
Yes, but luckily you also have at your disposal a suite of
real-world usage tests that exactly checks for the particular breakages
we're concerned with :-)
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk