Who is Fedora for?

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 ensued.

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 rate.

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 instructive:

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 this page for the contents of all of the proposals.

A rather contentious FESCO meeting was held on this topic on March 9. The apparent conclusion was to ponder further on Bill 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 seen.

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.