Boost logo

Boost :

Subject: Re: [boost] [test] Trunk broken: What happened to test_exec_monitor?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-04 15:16:14

on Tue Oct 04 2011, Gennadiy Rozental <> wrote:

> Dave Abrahams <dave <at>> 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.

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at