Subject: Re: [boost] trunk vs release
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-05-21 13:41:46
Robert Ramey wrote:
> This discussion demonstrates what's wrong with the current testing of the
> Here is the way it should be done.
> For each library that is changed, the library version on the trunk should be
> tested against
> the release branch. In practice this would work something like the
> On the tester's machine start out with a current image of the release
> For each library A
> switch library A's directories to the trunk
> run tests
> Restore image to release
Or (indulge me) more generally:
merge branch B with release branch
i.e., "library A on the trunk" is just a specific case of a branch,
and "switch library A's directories to the trunk" is just a specific
(painfully easy) case of a merge.
> This would
> a) attribute failures to their proper source
> b) prevent testing of each library (A) with provisional (trunk) code
> c) guarentee that when changes are merged into the release no new failures
> d) reduce testing time since a small expermental change in one library in
> the trunk
> wouldn't provoke rebuild and test of all its dependents.
> On my own machine, I have a release branch and I've switched the
> library directories to the trunk. I can verify that all the above mentioned
> benefits are in fact realized. Boost testing would benefit greatly from
> adopting the same strategy.
This sounds generally right to me, but I think there are problems. I'm
trying to be genericize it, and I'm not sure I've got it yet:
There is a 'testing' branch, to which libraries that are known to build
with the release branch (with say a couple of compilers) get merged, and
these libraries sit there until all-green: when that happens, they get
merged to release, i.e. the testing branch essentially becomes the
release. This way release *always* builds.
There are other cases where two libraries are mutually dependent; This
should be avoided but will happen. In this case they must go
simultaneously to the testing queue.
This implies that the testing branch is changing every so often.
serialization mpi parallel_graph
release <= testing <= upstream <= upstream
That is, a new release of serialization is in the testing queue getting
hammered on by testing drones. Next up is a new version of MPI, which
depends on serialization, and will have to build against whatever
version of serialization goes green for release. When serialization
reaches the testing queue a couple tweaks get made for borland,
something majorish gets backed out. The MPI will have to update (merge)
these new changes left-to-right through the queue and test privately to
be sure he's ready for the testing queue. This merge operation has to
be *easy* and quick.
And so on. parallel_graph, in this case, is watching the testing queue
and doing periodic merges and builds to be sure he's ready when it is
So the "switch library A's directories" mechanism seems to break down a
bit here; when serialization gets tweaked in the testing queue, MPI has
to somehow "switch directories"... and so on backwards up the queue.
I'm not seeing it quite yet.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk