From: Robert Ramey (ramey_at_[hidden])
Date: 2008-08-17 23:14:01
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.