A slight change to the freeze/release times
Jesse Keating
jkeating at redhat.com
Mon Feb 26 16:44:16 UTC 2007
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://lists.fedoraproject.org/pipermail/devel/attachments/20070226/ca06fbb6/attachment-0002.bin
More information about the devel
mailing list