The final Fedora alpha release?

The proposed change would first take effect in the Fedora 27 cycle. The idea is to replace the releases with an improved version of Rawhide, which would then serve as a sort of eternal alpha release. If Rawhide is always at an alpha level of quality, the thinking goes, early adopters will always be able to test the upcoming distribution. That should result in more testing over the course of the development cycle and, it is hoped, a more attractive platform for community developers. Meanwhile, the effort that goes into the creation of alpha releases could be directed toward other goals.

This idea may be an eye-opener for anybody who has followed Fedora over the years. Rawhide was launched in 1998 — well before Fedora itself, in other words. It has always been known as a bit of a rough neighborhood, a place for users who like to see something new on their systems every day and who are prepared for the occasional explosion. That notwithstanding, Rawhide was reasonably usable by sufficiently skilled people, but it took a turn for the worse some years ago. Back in 2012, Fedora developer Adam Williamson described Rawhide this way:

Needless to say, this does not sound like a particularly promising replacement for Fedora's alpha releases. In truth, though, the Fedora project has been trying to improve the reliability of Rawhide since those dark days. The no-alpha-releases proposal can be seen as a further step toward that goal.

A key part of this proposal is the "gating" of packages into the Rawhide distribution. Before an uploaded package gets into the Rawhide repository, it will have to pass a series of tests. Initially, the tests will focus on whether the package can be installed without breaking other packages; that alone will be a big improvement, since dependency issues are a familiar hassle for Rawhide users. The hope is to add more tests over time as the new workflow settles in.

The reception for this idea has been somewhat (but not uniformly) positive, though one might be tempted to disregard the input from a couple of frequent Fedora dissenters, some of which led to talk of code-of-conduct violations. Beyond that noise, though, there are some concerns, perhaps sharpened by the fact that the proposal was floated at the tail end of several particularly difficult days for Rawhide users. But, as Dennis Gilmore said, those problems are just the sort of thing that the gating mechanism is meant to prevent:

There are some users, though, who are worried about gating packages into Rawhide. They worry that this process would add delay and friction to the system and would essentially hide a number of problems from the bulk of Rawhide users, likely slowing down the resolution of those problems. Anybody who wants the truly raw Rawhide feed will still be able to get it by adjusting their package sources, though, so this may not be a big problem in the long run.

Another concern is that gating Rawhide in this way may make it nearly impossible to accomplish package transitions that affect a large part of the repository. A major version bump in an important language or library can create a fair amount of repository chaos that takes time to work out. Kevin Fenzi acknowledged that "the mass rebuild case will need to be excepted once it's 'good enough' or have some other way of landing". One possibility that was raised is that, in such cases, the strict gating would apply only to a restricted set of "core" packages.

Some participants saw this move as an attempt to turn Rawhide into something resembling a rolling-release distribution, along the lines of openSUSE's Tumbleweed. Indeed, Tumbleweed uses a similar gating mechanism to allow packages from the Factory into the distribution; the result is a rolling-release distribution with a high level of stability. Neal Gompa worried, though, that Fedora is not in a position to replicate Tumbleweed's success. For example, the project lacks the equivalent of the openSUSE Build Service which, among other things, can apply tests more quickly and can do automatic rebuilding of entire dependency chains. Over time, we may see Fedora following openSUSE's example with its infrastructure. As Fedora project leader Matthew Miller put it, "the openSUSE developers are awesome, and there's a lot we can learn from them, but if we have the will to do something, we certainly can."

At this point, the no-alpha-release proposal is exactly that: a proposal. If the discussion on the list is any guide, though, the chances of the proposal being accepted by the project are quite high. So it may well be that the upcoming Fedora 26 alpha release (currently scheduled for March 21) will be the last, and Rawhide will become a more stable option for those who want to live on the bleeding edge.