Looking forward to Fedora 8

Given the amount of work which went into the recent Fedora 7 release, it would not be surprising if the Fedora developers were to go off and focus on beer consumption for a little while. As it happens, the beer is (mostly) staying in the refrigerator and the Fedora community is getting a quick start on the Fedora 8 release; the beginning of a feature list is in the works. The draft schedule has been posted, and it is ambitious: Fedora 8 is due on October 31 (Halloween), after a mere five months of development.

This schedule has raised some eyebrows within the community. Five months seems quite short for the development of a new version of this distribution. The final development freeze is on October 17, which disappoints KDE fans: the KDE4 schedule calls for an October 23 release. If one looks at the feature freeze date (August 20), then Fedora 8 appears poorly aligned with the GNOME 2.20 schedule as well. Why, it is asked, should the Fedora project rush out a distribution under a tight schedule which causes it to miss the major developments that users are looking for?

The answer lies in the Fedora leadership's desire to get the distribution back onto a regular six-month schedule. A predictable release pattern is better for everybody involved. Users know when it will happen, and major development projects can, if they care, plan their own schedules around the distribution releases. Fedora's releases have been a bit less predictable than usual recently, an understandable result of the changes the project has undergone. But Fedora 8 looks like a good opportunity to bring things back in line.

That reasoning still leaves open the question of why this cycle needs to be only five months long. The Fedora folks are juggling a couple of other concerns here. One of them is that final distribution releases are best placed far from the end of Red Hat's fiscal quarters; it seems that it's a lot easier to get peoples' attention when they're not trying to close out a quarter. The Fedora leadership has also noticed that, just occasionally, Fedora releases have been known to slip back a bit from their planned date. Putting that date in October allows for a certain amount of slippage without pushing the release back into the middle of the holiday season. A Fedora release as a Christmas/Hanukkah/Kwanza/Yule present is a pleasant idea, but it's less pleasant for Fedora developers who may have other plans during that time.

The end result of all this is that Fedora is likely to cling fairly tightly to an April and October release schedule. We are seeing a similar pattern with some other distributions, and with other large projects. Over time, perhaps, some sort of loose, global coordination of release schedules across much of the community is emerging. That would be an interesting example of spontaneous organization where few expected it to happen.

Meanwhile, there is still some significant grumbling within the ranks of the Fedora developers who came from the Extras side of the distribution. Putting an updated package into the old Extras repository was a simple process; now the "short form" of the packaging guidelines shows a 15-step process to upload a single package. A new requirement to route packages through the updates-testing area was the last straw for some developers who were already unhappy with what they see as a heavy bureaucracy which has been imposed upon them. There is talk of having lost control of what used to be a community-oriented Fedora Extras distribution.

This discussion should be looked at with the understanding that the merger of Fedora Core and Fedora Extras was a major change in how Fedora is made. Naturally there will be culture clashes, growing pains, and conflicts as two very different sets of processes are merged into a single, new process. The path toward a solution was articulated clearly by longtime contributor Thorsten Leemhuis:

Disagreements within large projects are not uncommon, even without the added stress of major change. The open nature of projects like Fedora causes these disagreements to unfold in very public ways. The good news is that if the project's participants are serious about pursuing a common goal - creating the best free distribution they can, for example - they usually find a way to address the issues and move on. With any luck the remaining difficulties from the merger will be a distant memory by the time we're thinking that our Fedora 7 systems are getting old and are in need of an upgrade.

---

to post comments