Development process analysis
justdave at bugzilla.org
Sat Jan 8 22:12:23 UTC 2005
Vlad Dascalu wrote:
> Secondly, this 6-month thing never got the chance to run in a normal
> state. 2.18 had to catch up with several years of 2.17.x development and
> its regressions. 2.20 apparently will put things back on track if indeed
> is released shortly after 2.18, like David insists nowadays.
> 4thly, this rule has some kind of negative feedback loop. If it takes 3
> months to clean up after 3 months of development, then we'll have 3
> months of devel and 3 months of stabilization. If it takes 6 months of
> clean up for 3 months of development, then we'll have only 2 months of
> devel and 4 months of stabilization. It automatically adjusts the scale
> to 6 months, by keeping the proportions.
The stabilization period for 2.20 has actually been artificially
lengthened by my insisting that we release 2.18 first before we do a
2.20 release candidate. 2.20 was in theory ready to go when we released
2.19.1. Granted, there have been several more blockers found for 2.20
since then, but most of that is a result of the b.m.o upgrade, and would
have happened even if we had declared that the RC. Seeing how 2.20 went
with a 2 month checkin window before we froze for 2.20, I have very high
hopes that 2.22 will go even smoother once we reopen the trunk.
Development didn't stop, we just have several patches sitting in
Bugzilla waiting on hold to be checked in. It's a little frustrating
because they're not in CVS, but they're still coming anyway. Once the
trunk opens, those will go in, and we'll have 2 months (or slightly
less) to keep going with feature development before we have to freeze
for 2.22 in March, which is within a reasonable distance of how long we
had for 2.20 after 2.18 branched.
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Foundation http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
More information about the developers