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

From: Andy Stevenson (andystevenson_at_[hidden])
Date: 2007-08-10 16:18:22

On 10 Aug 2007, at 03:44, David Abrahams wrote:

>
> 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.
Agreed... hence the suggestion to cut down the area covered by the  
multiple layers of OS/compiler variants....?
>
>> 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?
That too :-)!
>
>> 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.

You're in a much better place to judge this than me. However I would  
seriously recommend moving the existing framework forward to gauge  
real requirements.
>
>> 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.

Sure,  I didn't intend that it addressed the reliability issues. My  
point was that from a reporting, support, release and development  
perspective boost may make more rapid progress if it cut down the  
'platform' area it tries to support as the 'vanguard' from  
development. In an area where skilled resources are scarce or  
unpredictable then could it be a pragmatic suggestion for addressing  
some of the key issues on developer feedback?
>
>> 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.

Yep. Read what John wrote and agree to most of it.

>
>> 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.
>
Sure, understand that... i think as svn is core to the boost  
toolchain is there a need to introduce databases into the toolchain?

Andy
> -- 
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
>
> The Astoria Seminar ==> http://www.astoriaseminar.com
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/ 
> listinfo.cgi/boost