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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-05-13 04:34:41

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.

- Volodya