Subject: Re: [boost] trunk vs release
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-05-21 15:11:30
troy d. straszheim wrote:
> 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've avoided the word "merge" as (at least in SVN) it does
updates the target which changes. switch (in SVN) is a merge
in this sense. For purposes of this discussion, consider
"switch" equivalent to changing a hard link to another directory.
> 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.
Basically we agree - this is an implmentation detail at this point.
>
>> 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:
I've found it helpful to do it on my own machine to get used to it.
It's very easy to get used to. There are a couple of things to be
aware of - like accidently changing something outside one's own
directory - but in general, it's very easy to get used to.
> 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.
I'm not sure what this refers to. Perhaps CMake. What I currently
do is
a) test on my own machine according to the above
b) upload to trunk and watch the tests.
c) when I feel good about it, merge to release.
b) would be more useful to me if testing on the trunk were as I describe
above.
> 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.
I'm not seeing that. If they are two libraries that are mutually dependent,
that would be a bad thing and contradicts the whole idea of a library
in the first place. If its a breaking change, that's a bad thing that will
happen but doesn't break the testing regimen.
> This implies that the testing branch is changing every so often.
I'm not sure what "testing branch" refers to
> 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.
All correct - and OK as far as I'm concerned.
> 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.
I don't see that I have to watch the queue. The only thing I have to do
is watch my tests for breaking changes in dependent libraries. Which
I have to do now in any case.
> 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.
Here's the scenario.
a) I make a breaking change to serialization.
b) after testing in the trunk - I merge into the release queue
c) MPI tests start to break.
d) I get an email from the MPI authors which starts Dear $#$#%$%$&$^*%^*
e) Haggling involving me, the MPI authors and perhaps the release manager
result in one of the following:
i) backing out changes in the serializaiton library
ii) MPI authors accomodating the change.
Robert Ramey