From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-08-17 15:45:03
Robert Ramey wrote:
> Beman Dawes wrote:
>> Probably, but I don't know how to attack some of the tool problems
>> otherwise. For example, the problem of people changing the tool chain
>> without realizing it has an impact on the automated release tools, and
>> the problem of the automated release tools no longer producing some
>> component (like docs) because of a tool change, and no one noticing.
> How about subjecting the tool chain the the same process as libraries are.
> That would be:
> a) proposal for boost tool - e.g. docbook.
> b) enough implementation, code, and test to request formal review
> c) normal formal review process
> d) normal acceptance process.
> e) normal test procedure.
> Test procedure would be similar to that of libraries. Test files,
> expected results etc. When all tests are passing, the release
> manager would have the option of permiting trunk version
> to be rolled into the release ready version.
> This would work well with other testing and release procedures.
> That is, testing and release would use the last released tool
> version, NOT the one being refined in the trunk. This would
> be in line with what I hope will be the future of boost in that
> libraries are tested against last release and rolled into the
> release ready version as they prove that they are ready
> for prime time.
I second that. And this is something I've been moving some of the build
and test tools towards. For example bjam follows an abbreviated version
of the above process. And I'm working on setting up some formal testing
of bjam and adding some of the test tools and doc tools along the way.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk