Re: [boost] [1.37.0] branches/release open for merges

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-08-21 00:52:46

Gennaro Prota wrote:
> Robert Ramey wrote:
>> In my view, the current system is a huge improvement over
>> the previous one.  It wastes a lot less time.
>
> OK.
>
>     [...]
>> This latest release has been much less painful than
>> previous ones with just a few snafus.
>
> From what I remember (I've been more than one year away) it was just
> a) the incredible amount of coupling between the different parts of
> Boost b) code complexity c) absence of Beman.

Absolultly wrong.

a) there is no more or less coupling between libraries than there ever was.
b) boost code is getting more complex - not less
c) The previous review manager engaged in a heroic effort for
almost a year.  There has never been any reason to question
either his competence to do the job nor his dedication to it.  The
job as it was defined was just not possible to do.

The problem is the following:

a) One cannot get his stuff tested until its checked into the trunk.
b) Once checked in, the test matrix has to be watched for about
a week to check all the platforms.
c) During this time the trunk cannot be considered ready for release.
d) Within a week - someone else check something in
e) All this implies that the trunk is not an can never be ready for
release.

In the past, this was addressed by attempting to coordinate
all the boost developers to check in up to a certain date X
and then run the test and have everything pass at once.

This can work fine with 1, 2, or even 10 or 15 developers.  But
obviously it cannot and does not scale.  This lack of scaling
manifested itself with each release taking more time than the
previous one until 2007 when it took a year.

The current system decouples unit testing from release.  After a
library is tested it goes into the release branch as soon as the
author and release manager agree that its up to quality.

So we have branch (the trunk) where libraries are tested
and a branch (release) which contain libraries thougth to be
ready to release.  Each developer can work at his own pace
and it is not required for everyone to be in sync to some
special date (which is never met).  Perhaps it might be
more fitting to name the branches LibraryTesting Branch
and ReleaseReady Branch.

The only problem that remains are interface breaking changes.
The current system highlights these and permits them to be
addressed more effectively.  Previously they were lumped
in with library coding bugs which failed promote the most
effective solution.  I have hope that this aspect will improve
now that its a lot more obvious than it used to be.

Robert Ramey