A slight change to the freeze/release times

[Jesse Keating]

In the past we've had a few different strategies for freezing and releasing 
test and final releases of Fedora.  At times we would freeze on a Monday, to 
release the following Monday.  This gave us roughly until Friday to have 
a "golden tree" so that the mirrors could sync all weekend.  However many 
mirror admins hated Monday releases, so we adjusted a bit and started 
targetting Tuesday's for release.  This was accomplished by moving the freeze 
day from Monday to Tuesday.  However this shortened the amount of time we had 
to get a tree ready and we would often lose the weekend for syncing by not 
having a tree ready in time, and continually slipping until Thursday.  Moving 
the freeze to Thursday and targetting the next Thursday for the release is 
not optimal either, as we still have two days of freeze where little work may 
get done (the weekend).

I've taken a look at what motivates our freeze time.

A) Have enough time where the tree doesn't change from under us so that we can 
stabilize things and target specific fixes

B) Have a tree ready for the mirrors at least 2 days before the release date 
so that we can ensure many mirrors are fully synced

C) Minimize the amount of time where development is stifled.

Motivation C really got me thinking.  How are the freezes stifling 
development?  In the past with previous build systems, Release Engineering 
would completely lock a buildroot.  During a freeze, nobody would be able to 
build a package for the development collection, instead all builds were 
redirected to a development-HEAD like collection and sit there.  Rel-eng 
would have to interactively "move" any of these builds back into the 
development collection to be included in whatever release we were freezing 
for (as well as rawhide for public testing).  This was tedious and often 
broken, especially when the freeze was lifted and trying to merge those 
builds back in.

With the new buildsystem we're using, we can create new tags very cheaply, so 
we've tried freezing a different way.  The day/time of the freeze, Release 
Engineering will create a new "freeze" tag and tag all the latest packages 
from the development collection with this new tag.  We would adjust the 
rawhide compose so that it composed from this new tag.  Developers could 
continue to build things into the development collection without change, 
rel-eng would tag specific builds we wanted in our release (and rawhide) with 
the freeze tag.  At the end of the freeze, the rawhide compose was again 
pointed at the development collection and thus no builds were lost.  This is 
better for keeping development from being stifled, however there is still the 
act of "turning off" rawhide.

Why do we turn off rawhide, or rather make it compose from the freeze tag?  
Mostly it is so that the community at large are using the same package 
versions we hope to have on the release.  Now with pungi, it is also so that 
folks "playing along at home" can do composes with the package set as well.  
We used to keep rawhide "shut off" until the release day of the test release.  
This was to hopefully catch any last minute bugs and possibly call off the 
test release.  However I think we need to re-think this a bit, since once we 
release something to the mirrors it is extremely difficult to prevent that 
from leaking out.

So, for a proposal, I propose that we keep the current freeze day of Tuesday.  
This allows for the general weekend/Monday clean up and final rush for the 
freeze.  I propose that we move the anticipated release day to Wed/Thu, 
leaving it somewhat vague.  We'd like to hit Wed, but more often than not it 
may be Thu.  I just don't want to send a slip note every single time we miss 
Wed.  I also propose that we "turn on" rawhide once we release the tree to 
the mirrors.  This should be either Monday or Tuesday of the release week.  
This keeps the time development is "stifled" short, while maximizing the 
number of business days that we have to get the tree in shape in time for the 
mirrors to sync, and adjusts the schedule to something a bit closer to 
reality.

Thoughts?
-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070226/ca06fbb6/attachment.sig>