Re: [boost] [1.36.0] Libraries with unmerged changes?

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-15 13:12:16

It is working better.  But I think things could be improved alot.

a) Testing on the trunk is not as helpful as it should be.  My
tests results fluctuate all the time as changes in other libraries
ripple through to my tests.  If I haven't uploaded anything
I can ignore this - but If I have, I have to check every
failure to find whether its something I have to deal with
or can just ignore.  That is, Trunk testing is not a
"controlled experiment".  From the perspective of
the developer, tests run at different times or on
different platforms can't be compared.  There is a
huge "random unknown" behind the scenes that has
to be "factored out" and this consumes a lot of time.

Proposal:All tests for a particular library should be run against
the latest or next release.

b) Changes on the trunk affect other libraries.  Currently
we have a situation where a change in config breaks
a serialization jam fie.  OK so we fix the jamfile in the trunk.
Now we merge into the release.  Uh-breaks again since
the config changes aren't merged into the release.  OK
we'll roll it back.  Now the config changes are merged
into the release. Damn, breaks again.  OK merge
the jamfile changes from trunk - again.  Obviously this
is a huge waste of time.

Proposal:Libraries which have been tested against the latest
or next release are merged into the release one at time
and tests are run on the "next release".  Failures here
indicate interface breaking changes which would either
be rolled back or addressed in each dependent library.
If all tests pass, the current state of the release is designated
"release ready"  and available for download from the SVN
tree.  The decision to make a "release package" would be
an independent one dependent on other factors such as
how much time has elapsed since the emission of the
previous "release package"

Result:

a) Lots of wasted time avoided.
b) better detection and control of interface breaking changes.
c) schedule is not a problem.  There is always a "release
ready" package.  Production of a "release package" is
no longer dependent of any particular library or tests.

Robert Ramey

Beman Dawes wrote:
> From my standpoint, it is working a lot better than the old system.