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: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, richard dot guenther at gmail dot com, mark at codesourcery dot com
- Date: Mon, 29 Oct 2007 10:50:45 -0500
- Subject: Re: GCC 4.3 release schedule
- References: <20071029102207.4750c4a2@concorde.artheist.org> <4725FF81.6050208@redhat.com>
> 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.
Ahhh... but you show the way to induce participation here:
> 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" :-).
This 0.9 stage idea is golden.
Why don't we just straight out rank bugs closed to merge priority? Most
bugs fixed means first merge in stage one, period. Second higest # of
bugs fixed means second merge, etc etc.
That really aligns things correctly!
-benjamin