Looking forward to Fedora 8
[Posted June 5, 2007 by corbet]
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:
So lets deal with it now -- for example by making "contributing to
Fedora easy again, get the community involved better into the
decisions process and make packagers happy again" one of the most
important "Features" for Fedora 8. Otherwise the merge might fail
in the end.
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.
(
Log in to post comments)