Boost logo

Boost :

Subject: Re: [boost] Boost.Build merge?
From: Eric Niebler (eric_at_[hidden])
Date: 2008-10-11 12:52:32


Robert Ramey wrote:
>> 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.
>
> I would agree with Validir on this. I see the process where one
> makes (maybe alot) of changes in the trunk and once in a while
> gets to a point where he thinks - this is a real improvement over
> the current release ready branch and then does the merge.

Yes, agreed. The granularity at which things get merged to release
should be at the feature level and bug-fix level, not the per-commit
level. Thanks for correcting me. It seemed to me that Volodya was
merging many complete and separate features at once. I'm saying a more
piecemeal approach would prevent this sort of hand-wringing about
destabilization.

But since the release branch had been tested with BB from trunk, my
hand-wringing was unnecessary.

>> Speaking of early freezing, I think we should be pragmatic.
> ....
>
> I would like to see all tests run with the boost build and boost
> test in the release ready branch. This would permit developers
> of these tools to feel comfortable about commiting changes which
> might break something without creating a lot of problems for those
> using these tools. This would permit boost build to progress
> at its own schedule and pace while maintaining an ever
> improving product for use by boost and others.

Agree.

> This would
> eliminate the requirement for any kind of "freeze"

Let me understand ... it would eliminate the need for a tool freeze *on
trunk*, not on release. A freeze on the release branch is essential and
standard practice. And IMO the freeze on tools should happen earlier ...
by some weeks as Volodya suggested ... than the freeze on libraries.

> The same goes for boost documentation which I would
> really like to use. But I don't feel confident that "it
> just works"

Heh, there's nobody here who would disagree with that.

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk