Freeze Approaching

[David Miller]

Albert Ting wrote:
>>      I feel pretty betrayed by this freeze date.  I spent most of my  
>> time working on bugs targeted for 2.20, and doing QA for 2.20, only  
>> to discover that there won't be more than a few days between the  
>> release of 2.20 and the freeze of 2.22.  This makes me ask the  
>> following question:  Assuming I'm here to work on 2.24, why should I  
>> even spend any time fixing bugs in, or QA testing, 2.22, if it means  
>> I will have little time to work on code for 2.24?
> 
> I have the same concern.  I'm still working on getting 2.20 deployed at my
> site and will continue to do so until 2.20 is finally released.  Granted,
> it also includes the current set of customizations.
> 
> So shouldn't the 2.22 freeze date be relative to the final release of 2.20?
> I would hope there would be at least a month gap, if not a few months gap.

According to the schedule we agreed on a couple years ago (and still 
haven't had a chance to fully test -- it needs one more cycle to play 
out on a level field and know how it'll really work), the freeze dates 
are supposed to be 6 months apart.  2.18 couldn't make it because 2.18 
was a HUGE cleanup job after 2 1/2 years of development without a 
freeze.  We froze for 2.20 on March 15.  2.20 *could* have made it, 
unfortunately, some poor decisions were made by me on a few patches as 
towards what to let in during the freeze, and we wound up with a lot of 
cleanup to do again because too much got let in too late in the game. 
We branched on July 7th.  As of tomorrow there will have been two months 
of open development for 2.22.  There's already been a LOT checked in on 
the trunk.  2.21 is already at a point worthy of being a new release. 
However, it's obvious at this point that 2.20 isn't going to get 
released by the scheduled 2.22 freeze date.  I have no intention 
whatsoever of freezing before 2.20 releases.  No matter how much we want 
to keep to the schedule, that's just stupid to do.  We confused 
ourselves enough running the 2.18 and 2.20 freezes concurrently last fall.

My proposal right now (subject to change, pending feedback from you 
guys, but this is what I'm strongly leaning towards right now) :

1. Our QA team is in the process of certifying the 2.20 final release 
right now.  Unless major problems are found, we'll have a final 2.20 
release in the next couple weeks.

2. We release 2.21.1 concurrently with 2.20.  This is fairly standard 
practice: Since we started doing development releases, we've attempted 
to release those early and often, and usually concurrently with 
everything else.

3. Whatever date 2.20 and 2.21.1 go out, we wait one month from that 
date to freeze for 2.22.  At this point, that means we will have had at 
least 3 months (and probably slightly more) of open development on the 
trunk.  For reference, when we froze for 2.20 on March 15th, it was one 
month and 3 weeks after 2.18 released.

4. When we freeze for 2.22, we release 2.21.2.

5. The 2.22 freeze will be short and sweet.  Having learned from the 
mistakes I made during the 2.20 freeze, I plan on playing hardball on 
enforcing the freeze this time.  This should get us a lot more time for 
open development on the next cycle.  It would make my day to see a 2.22 
release candidate 4 to 6 weeks after we freeze.

As I said above, this is subject to change based on your feedback, but 
that's what I recommend we do.

I really think trying to stick to the timed releases as much as we can 
is a good thing for us (the old release early and often thing).  But I 
don't want to alienate the developers, either.  This is, after all, a 
community-supported project, and we would be nowhere without the support 
of the community.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/