Anybody who has gone near the Fedora mailing lists recently may have
noticed that they have been a little...active. The discussions have
reached the point where the "hall monitors" have intervened to shut down threads
and many participants may have unsubscribed in favor of the relative calm
and politeness of lists like linux-kernel. It's easy to dismiss it all as yet another
Fedora flame war, but there are some serious issues at stake in the
discussion. What it comes down to, it seems, is that the Fedora Project is
still not entirely sure of who its users are or how to deliver what those
Fedora is a rapidly-releasing distribution, with a new version coming out
twice each year. Support limited to just over one year means that Fedora users
must upgrade at least once annually or find themselves in a situation where
security updates are no longer available. So one assumes that Fedora users
are people who have a relatively high level of interest in running recent
software, and who are not averse to updating that software with at least
moderate frequency. But, it seems, there are limits.
Back in October, Fedora 11 users were surprised to discover that a routine update
brought in a new version of Thunderbird with significantly changed
behavior. In January, another Thunderbird
update created trouble for a number of users. In March, some
KDE users were surprised to discover that a
"stable update" moved them to the 4.4.0 release, breaking things for some
users. In all of these cases (and more), contentious email threads have
Fedora does indeed not hold back on the updates; a quick look in the LWN
mailbox turns up over 600 package updates for the
Fedora 11 release - in just the last month. This is a release
which is scheduled for end-of-life in a few months. Many of these updates
involve significant changes, and others have been deemed "worthless". Regardless of worth,
there can be no doubt that all these updates represent a significant degree
of churn in a distribution which is in the latter part of its short life.
It is difficult to avoid breaking things when things are changing at that
The parts of the discussion which were focused on constructive solutions
were concerned with two overall topics: (1) what kind of stable
updates are appropriate for a released Fedora distribution, and
(2) how to minimize the number of regressions and other problems
caused by whatever updates are considered appropriate.
With regard to the first question, it seems that some Fedora maintainers
believe - probably with good reason - that their users want "adventurous
updates," so it makes sense to them to
push new versions of software into released distributions. Others describe their
vision of Fedora as a "rolling update" distribution which is naturally
following upstream releases. Others, instead, wonder why Fedora bothers
making releases at all if it is devoted to rolling updates; users who want
adventure, they say, can find plenty of it in Rawhide.
Several proposals have been put onto the release
lifecycle proposals wiki page, and others have been posted to the
list. They vary from nearly frozen releases to ideas that make releases
look like a moderately-slowed version of Rawhide. This decision is one of
fundamental distribution policy; it must be faced, or Fedora will continue
to have different maintainers doing very
different things. Given that need, it's unfortunate that the project seems to
be unable to discuss the topic on its mailing lists; there is no clear
means by which a consensus can be reached, currently.
Part (2), above, dodges the issue of what updates should be made and just
concerns itself with the quality of those updates. The discussion is
partly motivated by the fact that the system which Fedora has in place for
the review of proposed updates - Bodhi - is often
circumvented by updates which go straight out to users. The testing and
voting which is supposed to happen in Bodhi is, in fact, not happening much
of the time, and the quality of the distribution is suffering as a result.
So some Fedora developers are looking for ways to beef up the system.
Matthew Garrett posted a proposal for a new
policy which would eliminate developers' ability to push package updates
directly into the update stream. Instead, updates would have to sit in the
Bodhi system until they receive a minimal +3 "karma" value there; the only
exception would be for security updates. By disabling direct pushes, the
policy aims to ensure that every package which gets into the updates stream
has actually been tested by some users who were happy with the results.
Suffice to say, this proposal was not received with universal acclaim.
Some developers simply resent the imposition of extra bureaucracy into
their workflow. Karel Zak's response is
Fedora strongly depends on well-motivated and non-frustrated
maintainers and open source developers. We want to increment number
of responsible maintainers who are able to use common sense. Our
mission is to keep maintainers happy otherwise we will lost them
and then we will lost users and our good position in Linux
Always when I see that someone is trying to introduce a new rule I
have to ask myself ... why so large project like kernel is able to
successfully exist for 20 years without a huge collection of rules?
One might observe that the kernel has, in fact, accumulated a fairly
substantial set of rules over the last ten years, often in response to
discussions with a striking resemblance to those being held in the Fedora
community. The merge window, signoff requirements, review requirements,
no-regression policy, etc. are all aimed primarily at improving release
quality. The kernel also has layers of developers with something close to
veto power over potentially problematic changes - a form of dynamic
rule-making that Fedora lacks.
So rules might make sense; that says nothing about any specific proposal,
though. Many developers feel that very few users test packages in Bodhi,
and that large numbers of updates would languish there indefinitely. As Tom Callaway noted, the obstacles to getting
those karma votes are significant. So
one alternative which has been suggested is that, after 14 days
without negative karma, a package would be allowed to proceed to the update
stream. Other proposals have included requirements for regression tests or
separate (more stringent) requirements for "critical path" packages; see
page for the contents of all of the proposals.
contentious FESCO meeting was held on this topic on March 9. The
apparent conclusion was to ponder further
Nottingham's proposal, which involves regression testing and a
requirement for positive Bodhi karma for all "critical path" and
"important" components; others could proceed after a week in the
updates-testing repository. It looks like another meeting will be held in
the near future; whether it will come to concrete conclusions remains to be
The "concrete conclusions" part is probably more important than the
specific policy adopted (within reason) at this point.
Many large and successful projects go through the occasional period where
they try to determine what their goals are and how those goals can best be
met. Properly handled, these discussions can lead to a more focused and
more successful project, even if much heat is generated in the process. A
good outcome, though, requires that there be a way to end the discussion
with a clear conclusion. Fedora has governance institutions which should
be able to do that; until those institutions act, Fedora risks
looking like a contentious organization lacking a clear idea of what it is
trying to do.
to post comments)