Inspired by the QA Retrospective that James Laska and the QA team created over the life of Fedora 13, I’ve created a Fedora 14 Schedule Retrospective page.  Everyone participating in the Fedora 14 release cycle, from any team, is welcome to add helpful information to this page.

Following my motto that you get what you track I’ve set out to capture more detailed data on what works and what doesn’t in our release schedules.  There is a better chance of releasing Fedora 14 on time if we are cognizant of all the moving parts and tracking them in real time.

To be clear, the schedule retrospective page is not a personal hall of shame, nor should it be used as such.  It tracks successful events we want to repeat.  It also tracks unsuccessful events we do not want to repeat.  The benefit of doing this as the release progresses is that we can learn as we go and course correct along the way–the beauty of iterative improvement.

A great example of the benefits of this process are the first entries recording the run up to the Fedora 14 Alpha release.  Starting last Thursday and for the next three weeks, Release Engineering is responsible for creating installable images for QA testing and consumption.  That means we have four chances to iron out the process and get it right before it really matters–composing the Fedora 14 Alpha Release Candidate.  If the release candidate is not ready on time we risk not having enough time to validate it without having to slip the schedule.

During “Create Installable Images for QA testing #1” we had a few things that didn’t go as planned, a three task pile-up of sorts:

  • The correct version of Anaconda arrived late in rawhide
  • Release Engineering did not have resources to compose the release
  • The build system (Koji) was down all weekend for scheduled maintenance

The second and third issues might not have been a factor if the first one hadn’t.

For example, in the process of “Create Installable Images for QA testing #1” maybe we could have checked to earlier to see if the right Anaconda was in rawhide.  Perhaps we should send development reminders before these composes.

The case of not being able to compose the distro calls out the need for more knowledge sharing and delegation of tasks in the Release Engineering ticketing queue.  Our processes are not sustainable and the chances of consistently hitting our schedules are low if we are dependent on one person to complete critical tasks.

It is impossible to eliminate or reduce to zero the things that can go wrong. The key is to have processes and backup plans in place to mitigate the damage when they do.  Help Fedora improve its release processes by contributing to the Fedora 14 Schedule Retrospective.