Re:Re: [boost] Re: 1.32 release preparation

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-06-28 09:58:28

Message: 16
Date: Sun, 27 Jun 2004 22:25:47 -0500
From: "Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]>
Subject: Re: [boost] Re: 1.32 release preparation
To: boost_at_[hidden]
Message-ID: <40DF8FBB.4040408_at_[hidden]>
Content-Type: text/plain; charset=us-ascii

Aaron W. LaFramboise wrote:

>Robert Ramey wrote:
>> Dave Abrahams wrote:
>> 
>> 
>>>I'd like to know the reasons for "all the sudden rush".  We did
>>>announce a schedule long ago, and it has already been delayed by three
>>>weeks.  I'm not asking in order to point fingers; I just want to know
>>>how to avoid the "sudden rush" next time.
>> 
>> 
>> Here is the current scenario. 
>> 
>> a) The announcement gets posted - release 1.32 scheduled for date x.
>> b) Each developer decides - uh oh I better get in my changes before date
x.
>> c) Of course these changes take longer
>> d) and break some other things
>> e) which takes longer still
>> 
>> Personally I think the concept of scheduling a release fundamentally
flawed.
>> I would suggest another idea.

>As an observer, I'm fairly impressed with GCC's release methodology.
>http://gcc.gnu.org/develop.html

>A critical component is a schedule that includes several stages during
>which certain sorts of changes are unacceptable.

>There's still rush, but most of the rush for major features or other
>destabilizing elements happens long before the release comes around.

I found this to be very interesting.  I had never seen this before.  It
basically implements my view that the "Main Line" should be code that is
always works and is ready to be used, tested and potentially released.  As
far as I'm concerned it's totally consistent with my proposal which I
thought was un-orthodox but now see that is used at least by GCC.

So, my view would be - stick to the original 28 June date, require that new
libraries be added to branches and merge to main as appropriate.

I realize its not THAT easy - but it would address the concerns that I have
about the whole process and allow all libraries to proceed on independent
schedules.  New libraries would be tested against the "known good tree"
independently of one another.

Take as a small example changes in MPL.  The current method is to check in a
new version of MPL and see what happens.  Presumable some issues will arise
and now we have a broken system which inhibits development of other
libraries until the issues are resolved.

Under the proposed method, the new MPL would be check in under its own
branch and issues would be detected on all libraries before they affect
other developers.

Anyway - my 2 cents.

Robert Ramey