This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.3 release schedule

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]