Re: [boost] trunk vs release

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 
> trunk.
> 
> 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 
> following:
> 
> On the tester's machine start out with a current image of the release 
> branch.
>     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
   run tests

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 
> occur.
> 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 
> serialization
> 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.

Diagram:

            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 
his turn.

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.

-t