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
