Development process analysis

[David Miller]

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.

Yup.

> 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/