On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> 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 by contributor. Those get to merge last, as they didn't show incentive to maintain their merged code (and yes, this happens). Richard.
