This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.3 release schedule
On 10/29/07, Benjamin Kosnik <email@example.com> wrote:
> > 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!
I'd rather rate along highest # of bugs still open in subsystem merged
Those get to merge last, as they didn't show incentive to maintain
their merged code
(and yes, this happens).