Re: [boost] Boost.Build merge?

Subject: Re: [boost] Boost.Build merge?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-10-11 02:04:00

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?

The development process for libraries, at least that on

        http://svn.boost.org/trac/boost/wiki/ImprovingPractices

does not require that library changes be changed piecemeal, and as I say
in other email, I think it would be a mistake to require piecemeal merge of
changes. It only imposes additional overhead. 

There are cases where splitting a big change into individual chunks is
desirable. E.g. this is what happens with GNU projects usually, where folks
try to split large work into logical bits, exactly because somebody should 
sign-off on each patch. But preparing such a clean patch series takes a lot
of effort, and also note that even with GNU projects, it's considerable
acceptable to only test that middle patch compile, and run tests on full result.

But in current case, that example is not even relevant, 
   - we are not talking about any big feature checked in to trunk, but a number 
   of individual unrelated changes that should be on release. Every project I know
   (including GNU project), creates fresh release branch out of current trunk state.
   Piecemeal merges are reserved for important changes on trunk *after* the release
   cut-off date.

Speaking of early freezing, I think we should be pragmatic. Freezing tools are the
start of release cycle means that if I make any good change at the beginning of release
cycle, then it won't be merged until next release cycle (3 months) and won't be released
until next release (3 months). So, there's 6 months delay, which seems like disservice to
users. I'd agree that some advance merging to tools makes sense given their global impact,
but I think that the additional freeze time should correspond with risks. E.g. take release
N, and measure the time during which release results were unstable due to tool issues. Let
that be U weeks. Require tool freeze for the next release to happen U+1 weeks before the
libraries. 

- Volodya