> 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
