Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-09 22:44:51

on Wed Aug 08 2007, Andy Stevenson <> wrote:

>> While I acknowledge that Boost's feedback system has substantial
>> weaknesses, no other feedback system I've seen accomodates most of
>> these features in any way.
> I agree. I've had numerous experiences with large projects that
> have not done it as well as boost.

I wasn't trying to make a value judgement, FWIW.

> Personally I find the status information held by meta-comm to be
> useful and informative. The opening page isn't very useful but
> digging in always leads to the information that is most useful.

Yes, you can get there. It should be easier.

> Generally I agree with all the recommendations. However I am a big
> fan of incremental delivery and I would advocate boost approach this
> systemically.


> You don't want to get into the tool business. (.. avoid the
> anecdotal 'why fix things in 5 minutes when I can take a year
> writing a tool to automate it! :-{)

I'm afraid it's inevitable in this case, unless we can get someone
else to do it for us.

> For what it is worth my advice would be to do the following;
> 1. Choose 2/3 representative tool-chains/platforms as boost
> 'reference models' (msvc-M.N, win XP X.Y...) (gcc-N.M, debian...)
> (gcc-N.M, MacOSX,...)
> - the choices are based on what's right 'for the masses' and what is
> the defacto platform for mainstream development on those platforms
> (before anyone screams I am seriously NOT advocating dropping the
> builds on the other platforms - read on)
> - whatever the choices end up being I believe 'boost' needs to make a
> clear policy decision.
> 2. These 'reference models' are the basis of summary reports at the
> top level against the 'stable' released libraries. That can go on a
> page and it should take a minor amount of time to generate
> incrementally from the existing system.

That won't fix the system's reliability.

> 3. As for tracking individual test results I don't personally see
> what's wrong with putting these under subversion.

See several responses on this list to John Maddock, who made that
suggestion too.

> Given the likelyhood of high commonality between the output text of
> successive runs I think it is a much better 'implementation choice'
> than strictly a database.

You can store diffs in a database too.

Dave Abrahams
Boost Consulting
The Astoria Seminar ==>

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