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
Attachment:
pgpr0gy5diMXh.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
