Re: [boost] Boost.Build merge?

Subject: Re: [boost] Boost.Build merge?
From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2008-10-11 00:49:06

On Oct 10, 2008, at 6:45 PM, Eric Niebler wrote:

> 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?

Hi Eric,

I'm personally in favor of the longer testing cycles that you  
propose.  That said, there are changes in Boost Build and Bjam that  
I'd like to see in 1.37, so I'd support your suggestions starting  
with the 1.38 release. Given the track record of previous tools  
releases, I'm quite comfortable with the changes Rene and Volodya  
want to merge into the release.  If it would help, I'd be willing to  
run additional tests on the release platforms if that will help  
ensure confidence in the tools changes.

-- Noel