Re: [boost] Boost.Build merge?

Subject: Re: [boost] Boost.Build merge?
From: Eric Niebler (eric_at_[hidden])
Date: 2008-10-10 20:45:06

Rene Rivera wrote:
> Eric Niebler wrote:
>> Vladimir Prus wrote:
> 
>>> To reiterate, I think Boost.Build should be merged because:
> 
>> The development process should work like this: you make a change to 
>> trunk, wait for tests to cycle, and if they look good, you merge the 
>> change to release. The process should *not* work like this: you make 
>> change after change to trunk, and wait until the very last minute to 
>> drop them all into the release branch at once.
> 
> Perhaps there's been a slight misunderstanding. Keep in mind that build 
> tools infrastructure is treated somewhat differently than library code:
> 
> * The Boost.Build changes always get tested on trunk, and on the release 
> branch.
> 
> * AFAIK there have been numerous cycles of the Boost tests with the 
> changes Volodya has in mind.
> 
> * We have traditionally merged Boost.Build to the release at the very 
> last minute to have the release contain the most accurate state of what 
> we test. Although in the last release we froze the tools code shortly 
> before the release to reduce the chances of problems.
> 
> Hence:
> 
> * There is no advantage to not merging Boost.Build to release.
> 
> * It's actually a disservice to users and library authors since it would 
> make for discrepancy between what is tested and what is released.
> 
> * When the Boost.Build merge to release happens it also means that the 
> Boost.Build code will also need to be frozen on branches/release and on 
> trunk. At which point Volodya, Jurko, myself, and others get to either 
> avoid doing Boost.Build stuff or work in other branches.
> 
> Consequently I'm not only in favor of merging Boost.Build to release, 
> but I'm insisting it's required.
> 
> Note, this special arrangement may change in the near future. But for 
> now we've tried to make the Boost.Build development as minimally 
> disruptive and maximally advantageous as we can manage.

Thanks for filling me in on the state of affairs. You're saying the 
release testers are using Boost.Build from trunk? I find that 
surprising. What prevents instability on trunk from hosing the release 
tests, which would be really unfortunate? Why is this better than the 
normal procedure of changes to BB on trunk getting tested there and 
merged piecemeal over time to release? Then the release branch can be 
tested with BB from release. I've missed some rationale here.

Anyway, I'm all for syncing what we ship with 1.37 with what we've been 
testing on the release branch. If that means merge, then by all means, 
do it.

But let's please rethink this procedure. The process for the tools 
should be the same for the libraries, IMO, with the exception that tools 
get frozen early. And the release branch should be tested with tools 
from the release branch. And changes are merged to release piecemeal and 
not all at once. Objections?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com