Re: [boost] Release Tools Analysis Part II: Developer Feedback Systems

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

on Wed Aug 08 2007, Andy Stevenson <andystevenson-AT-mac.com> 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. 

Systematically?

> 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
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com