Re: [boost] Proposal for radically altered approach to releases

From: Edward Diener (eddielee_at_[hidden])
Date: 2006-05-13 20:02:59

Vladimir Prus wrote:
> Jeff Garland wrote:
> 
>> Beman Dawes wrote:
>>> The current approach to getting releases ready is completely broken in
>>> my opinion. Each release requires heroic efforts by the release manager,
>>> careful attention by many developers, and endless delays until
>>> everything is just right.
>> No doubt that the process is broken.  I will say though, part of the
>> problem has always been nicely waiting for fixes to be made.  Releases
>> could trivially be made by reverting any library with regressions to the
>> version in the previous build.  This is similar to what you are
>> proposing, but would be more on the shoulders of the release manager to
>> be ruthless about meeting the deadlines.  The current release, for
>> example, would be progressing much faster if we just took the obvious
>> position: v2 build system isn't stable enough, revert to v1 and move on.
>> v2 will be in the next release.
> 
> Huh? Sorry, this is FUD. Though V2 initially caused quite a number of issues
> on it's own, they were fixed pretty quickly, and the remaining issues can
> be knocked down quickly too.
> 
> The problem is that I don't see any effort to close other issues. Let me get
> specific:
> 
>   - There's date_time failures with FelipeAlmeida and Bronek_office runners,
>     which use V1. How V2 prevents you from investigating them? 
>   - The concept_check and mpl libraries fail across *all* toolsets. I've
>     reported this here, twice, and nothing is still done.
> 
>>> The problems with the current release approach are not caused by release
>>> managers or developers, but rather by the release system itself. It just
>>> doesn't scale up to the number of libraries now in Boost, since every
>>> library has to be ready before a release can occur.
>> Again, it's mostly because the release managers are too nice.  I'll
>> volunteer to be the next release manager, I'll set a date, and I'll
>> pretty much assure you that it will go out on or about that date because
>> I'd cut any change off that wasn't ready.  
> 
> How about reverting date_time to the version that was shipped with 1.33,
> right now, on the grounds of there being test failures?
> 
> Sorry if that sounds rush, but I simply don't think that "revert war" on
> mainline is a best way to handle anything.
> 
> The "stable branch" idea from Beman, on the other hand, sounds quite
> feasible. It might be even better if merges to stable branch are done by
> release manager only, so that he gets full control of what goes to release.

The whole point of Beman's proposal is against this last statement. The 
point is that each library developer should be responsible for getting 
their library into the stable branch and maintaining that stability at 
all times. If a library is put into the stable branch with some change 
which breaks another library, it needs to be backed out until the 
appropriate libraries are coordinated to work together at the stable 
branch level.

The release manager is then freed to set the appropriate dates and get 
out the release.