Re: GCC 4.3 release schedule

[Andrew MacLeod <amacleod at redhat dot com>]

Benjamin Kosnik wrote:
>   
> > I'd rather take the make the dot-zero release approach while branching
> > and count on interested people fixing bugs on the branch after the
> > dot-zero release.  This way if nobody is interested on a particular
> > release series then we can declare the dot-zero release final -
> > otherwise we'd do more releases from the branch anyway.
> >     
>
> Quite honestly, I think a version of this basic idea is an improvement
> over the current vague procedures, and certainly worth trying. I would
> be open to experimentation in the gcc release procedure, especially
> after the trials of the 4.2.x series.
>
> Aligning Stage 1 freedoms immeidately after the confinements of Stage
> 3 branch/dot-zero-release seems to be the most natural way to motivate
> work on Stage 3 fixing/polishing. Our current procedure works against
> this natural flow.
>
> So, the way I see it, something like this:
>
> - now till < 100 bugs: Stage 3. Weekly bug counts sent to gcc list.
>
> - < 100 bugs: mainline freeze, branch, lockdown for two weeks. All
>   hands on board for release. All checkins must have bz#. End two week
>   lockdown with 4.3.0 release candidate 1.
>
> - 4.3.0.rc1 release, mainline Stage 1. + 2 weeks, 4.3.0.rc2. 
>
> - 4.3.0.rc2 + 2 weeks, 4.3.0 final. (or mainline Stage 1 here?)
>
> Temporary pain for long-term gain.
>
> Anyway. I'm surprised this suggestion did not get more comments. This
> is much more transparent than current procedures, and has a chance of
> focusing the gcc community on releases, not on the wide-open gates of
> Stage 1.
>
> -benjamin
>   
The only problem, is that anyone doing stage 1 work is already doing so 
in a  branch, and history (at least as I remember it :-) is that if  
little johnny doesn't have a pressing need for the current release, he 
will simply keep plugging along on his branch until stage 1 happens, 
whether its 2 weeks away or 3 months.

But yes, Id still be in favour of trying this or anything else which 
might help. Cut a release branch, and simply refuse to open stage 1 
until we release. Something has to help.  Often there is a race for 
merging branches when stage 1 opens (the earlier you merge, the easier 
it is). Maybe we can have a short stage 0.9 for merging of branches/work 
to mainline for those that contributed to getting the release out.  
Maybe that would help too, but then you'd have to define "contribution" :-).

  Ultimately, we need to get people interested in actually getting a 
release out.  I don't know of an easier way do that than aligning your 
desire to have a release with someone else wanting to use it. That at 
least motivates them, and locking into stage 3 until its released may 
encourage others to assist.

Andrew