Development process analysis

Vlad Dascalu vladd at
Sat Jan 8 21:33:12 UTC 2005

To be blunt, I don't like this very much.

First, because we'd broke in this way kind of a promise about scheduled 
feature freezes.

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.

Thirdly, the whole aim of "Shorter development cycles" would be broken 
if we'd do what you suggest, by pushing/enlarging this particular 
development cycle.

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.

If you mess with it, probably it will reflect in a longer stabilization 
period for 2.22, because you won't be able to change the stabilization 
versus devel ratio with this artificial extension. Although, suggestions 
for changhing the ratio are most welcomed!


Gervase Markham wrote:

> Guys,
> We're doing a lot of thinking about the development process at the 
> moment. However, it seems to me that we haven't yet had a chance to 
> implement the last round of thinking, and see whether the things we 
> wanted to do then actually improve matters. This means that a lot of 
> the discussion is merely rehashing the same points from six months ago.
> I seem to remember that the consensus was that the following things 
> needed to happen:
> - More frequent upgrading of b.m.o. for testing purposes
> - Shorter development cycles to avoid long stabilisation periods
> However, as we haven't yet released 2.18 or 2.20, we haven't had a 
> chance to put this into practice!
> If, once we branch for 2.20, instead of saying "according to the 
> schedule, we are now three quarters of the way through the 2.22 
> development cycle; so we only have a month to get patches in", we say 
> "OK, the 2.22 development cycle starts now", we can get back on track 
> and start trying out some of the last round of process improvements. 
> Then, we can see if they actually work! :-)
> (I'd argue we actually want to move to nine-month cycles, but that's a 
> different discussion.)
> Gerv
> -
> To view or change your list settings, click here:
> <>

More information about the developers mailing list