With the arrival of feature freeze for Fedora 14, things are about to get a lot more interesting. I haven’t talked about the full release processes in a while so hopefully someone out there will find this useful towards understanding the cadence–to borrow a scheduling term from our friends at Ubuntu :)–of our release cycle.

Here’s how things will roll from here towards the public release of the Fedora 14 Alpha. This same cycle repeats itself for the Fedora 14 Beta and Final releases.

  • 27-Jul :: Feature Freeze–All features must be significantly complete or deferred to Fedora 15.
  • 29-Jul :: Test Compose–Release Engineering Creates a “test” compose for QA to run tests on. This is helps make sure we the Release Candidate is in good shape on 05-Aug.
  • 29-Jul to 04-Aug :: QA tests the “Test Compose.”
  • 03-Aug :: Alpha Change Deadline–No more new packages are pushed to stable unless they fix Fedora 14 Alpha blocker bugs.
  • 05-Aug :: Compose Alpha Release Candidate (RC)–Cannot occur if there are open Fedora 14 Alpha Blocker Bugs.  If delayed by too long, impacts testing and delays the release
  • 06-Aug to 11-Aug :: QA tests the Alpha Release Candidate to validate that the release criteria have been met.
  • 11-Aug :: “Go/No-Go Meeting“–QA, Development, and Release Engineering gather to evaluate any unmet release criteria in the form of Fedora 14 Alpha Blocker bugs.
  • 12-Aug :: “Release Readiness Meeting“–At this meeting all of the teams involved in the Fedora release cycle gather to make sure everything is well coordinated and in order for launch day.
  • 12-Aug :: If there are no unresolved blocking issues from the “Go/No-Go” or “Release Readiness” meetings, release engineering will stage and start synchronizing the Fedora 14 Alpha to the mirrors. It takes a few days for all the mirrors to synchronize the release.
  • 17-Aug :: Fedora 14 Alpha Public Availability–At 10:00 AM Eastern Standard Time, Release Engineering does the “bit flip” and all of the mirrors make the pre-staged Alpha release available to the world.

In the event that the release candidate cannot be successfully validated (all specified tests run and no unresolved blocker bugs), the alpha release is delayed by one week, a new release candidate is built and tested, and all subsequent tasks start a week later including the final release date.

See the Fedora wiki for More details about Fedora’s scheduling methodology.  The full release schedule is also on the wiki.

With the Release Candidate compose date a little over a week away, here are important ways you can help increase the likelihood of the Fedora 14 Alpha shipping on time:

  • Provide timely status to blocker bugs you are the owner for–it may be obvious to you what’s going to happen, yet beyond bug comments, most people can’t tell if the bug is being worked on or not.  Help us all know.
  • Vigilance about fixing known Fedora 14 Alpha blocker bugs now–Addressing existing Alpha blocker bugs now gives us a better chance at creating the release candidate on time.
  • Save nice-to-have bug fixes for after the alpha release.  Only push new packages that fix Fedora 14 Alpha blocker bugs.  Every code change increases the risk of introducing an unknown issue, potentially delaying the release.
  • Help the QA team test the “Test Compose” on Friday.
  • Resist the urge to check-in untested, last minute changes–our release cycles are short.  Save it for after the alpha.

Having watched the mechanics of seven full Fedora release cycles go down (21+ test and final releases) these are the key areas that tend to derail us.  Unanticipated problems can and will show up.  We’ll be better to prepared to handle them if we address the issues we already know about as soon as possible.

This is why I’m harping on the Fedora 14 Alpha Blocker list on the Fedora development list and why I believe it can pay off. Help prove me right!