One thing that could improve the Fedora project is a schedule showing durations–how long tasks take. When making decisions about when to release or freeze we do not currently have the ability to quickly calculate how long something will take. An area I have rarely seen discussed is how long Fedora should allot for testing a particular release. It has never appeared on our schedules. Is this a reflection of what we value, something we simply haven’t considered about or ? A previous Fedora Board meeting about quality releases prompted these thoughts.

Up until now Fedora schedules have only had simple milestones for freezes and release dates such as Fedora 8. A quick read of the schedule makes it hard to determine how much time is spent on each task without taking time to do the mental math or pulling out a calendar to count the days. Looking at the Fedora 8 schedule you cannot tell how time was scheduled for testing.

Some will quickly suggest that testing happens all the time and that you do not have to wait for a specific test release or beta to start. While this is true, the only people who really do this are rawhide users–folks who who consume package updates in an ongoing fashion from the development repo as they are released. Others may argue that using the latest distro creation tools allow anyone to create their own out-of-band release for testing.

Realistically, the average user only downloads and installs official test releases. Official test releases provide a rallying point, a target, a goal–something tangible to test. We need the critical mass of people that download the official test releases and we need to be able to point them to a distinct block of time when their feedback is valuable–we do this from time to time on mailing lists, but I am suggesting something that is planned–that anyone can refer to.

Managing a detailed schedule does not have to be difficult. One of the most mature open source scheduling tools I have found is TaskJuggler. It would be a great addition to managing the next Fedora release. Updating a TaskJuggler file takes a fraction of the time it takes to look up dates on a calendar, count in between, and then update the wiki (only to find that some dates have landed on the wrong work day)–our current approach.

TaskJuggler would help us:

  • create more complex schedules and re-factor them quickly
  • track our schedule performance (planned vs. actual)–how well are we able to do what we thought we could?
  • generate iCal files for your online calendar or PDA
  • automatically generate milestone report (what is on the wiki now)
  • calculate task durations
  • draw cool gantt charts to show management–we don’t have management, we’ll have to create some 😉
  • plan farther into the future by being able to overlay current releases with planning for the next and evaluate the consequences
  • calculate the days/weeks so they always land in the right spot
  • create micro schedules by group (release engineering, docs, infrastructure, etc.) which can be combined in one macro schedule and viewed as desired

Using the proposal that Jesse Keating wrote for changing the Fedora 9 release structure I created a schedule with task durations and testing dates here. There are a variety of examples linked to this report–including the milestone report we already use. The crazy part of all this is that the TaskJuggler source file to generate all this coolness is only about 175 lines long. The source code is here.

TaskJuggler takes a unique approach as a GUI application–more of a viewer as everything is constructed by code–and a first attempt or two at using it can be frustrating. On the other hand it is a very powerful scheduling application that requires an investment of time to understand and use well. I believe the return on investment is worth it and I’m glad to maintain the files and reports and post tips on how to use it.