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