This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.3 release schedule
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: gcc at gcc dot gnu dot org, richard dot guenther at gmail dot com, mark at codesourcery dot com, amacleod at redhat dot com
- Date: Mon, 29 Oct 2007 10:22:07 -0500
- Subject: Re: GCC 4.3 release schedule
> 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