The Debian project is again seriously discussing proposals to add a user-centric, frequently-updated distribution product to its public offerings. The concept centers around providing a rolling release with a continuous (and therefore current) stream of package updates, as an alternative to the well-honed (but frequently behind-the-times) Debian stable. Most of those involved seem to agree that offering a "Debian rolling" product would benefit the project, but the debate persists over how much it would cost in terms of developer and release-team time — and how that investment would affect the existing release process, which is tailored toward the production of stable.

The idea spun off from discussions around the constantly-usable testing (CUT) Debian concept in a 2007 proposal from Joey Hess, which observed that many users are unsatisfied with the age of packages in stable, and choose to run testing instead. Debian should adjust its release process to better serve those users, Hess said, by making sure that testing was always installable, and by providing more timely bug fixes.

The CUT concept was resurrected at Debconf10 in August of 2010, and since then the debian-devel list has hosted numerous discussions and refinements — including offering rolling releases. The proposals ranged from simply re-naming Debian "testing" as "rolling," to creating regular snapshot releases of testing, to changing the release process in large ways — including the freeze process and even the relationship between unstable, testing, and stable. The latest discussion spans hundreds of individual messages, which prompted Lucas Nussbaum to write a blog post on May 2nd in an attempt to summarize the discussion and the current state of the proposed course of action.

Where rolling stands

Nussbaum starts out by clarifying what supporters of Debian rolling see as the benefits of the sub-project. First, providing a reliable rolling-release will attract new users (and perhaps new contributors) to Debian, in particular those who are uncomfortable using Debian testing because they perceive it as a development branch, but for whom the packages in Debian stable are too old. By doing nothing, he said, Debian currently cedes these users en masse to Debian derivatives like Linux Mint, Aptosid, and Ubuntu.

Second, a successful Debian rolling product would help upstream projects to gain new users more quickly, providing valuable feedback more rapidly than is possible in the traditional release cycle. There are, of course, other rolling-release distributions (including the Debian derivatives mentioned above), but Nussbaum seems to think that Debian would be offering a unique rolling product by virtue of its size and proven history as a major distribution. Finally, a Debian rolling product would bring more attention to the Debian project, which is often overshadowed by the Debian derivatives in the news, which in turn makes recruiting new contributors difficult.

As for the plan itself, Nussbaum said that it is "mostly about (external) communication" and that it will require "marginal additional work". It would start with a general resolution (GR) from the project members, announcing the testing->rolling name change, Nussbaum said. Raphael Hertzog has already drafted a proposed GR to that effect. Accompanying the name change would be a committed effort on the part of Debian developers to support the packages in rolling with regular updates that prevent breakage of major components, and integrate security-related or other important patches from unstable.

The big unanswered questions at the moment are how to handle the freezes that occur before releasing a new stable. Testing is currently frozen for around six months while stable is prepared, a length of time that could be considered a painfully long freeze for a "rolling release." The options Nussbaum enumerates are to create a "frozen" branch from rolling (and develop stable from frozen on approximately the same six-month time-frame), or to freeze rolling for a shorter amount of time (such as three months), then create the frozen branch and unfreeze rolling.

Both options would create two releases (rolling and frozen/stable) that for at least some portion of each release cycle would each demand divided attention from developers: some working on the frozen branch to prepare it for release as stable, and others continuing to test and update the packages in rolling. This division-of-effort is one of the most common objections to the proposed plan, but Nussbaum argues (as does Hertzog) that this is already the case: as a group, Debian developers must divide their attention between developing for stable-plus-one (in unstable and testing) and back-porting critical updates to stable. The main difference, he insists, is that the proposed plan would do a better job of providing an accessible "Debian product" in between stable releases.

On the other hand, Nussbaum concedes that during freezes, there would be multiple "entry points" for actual packages. Debian unstable would continue to be the entry point for packages promoted to rolling, while frozen-proposed-updates would be the entry point for packages targeting frozen/stable.

Objections and other options

The testing->rolling plan outlined by Nussbaum is not the only proposal under consideration. Other suggestions focus on making smaller changes to the existing development process, so that testing is a better platform for daily usage. For example, reducing the number of architectures required to migrate a package from unstable to testing and encouraging developers to rebuild packages for testing-proposed-updates instead of for unstable would both get packages into testing more quickly, to the satisfaction of users interested in up-to-date packages.

Other proposals include implementing Apt repositories for different packages a la Ubuntu's personal package archives (PPAs) for developers, and attempting to streamline the packaging process as a whole (thus hopefully reducing the length of freezes themselves) so as to speed up development. The PPA idea does not seem to have widespread support, partly because it has high infrastructure requirements, partly because it might require all involved to settle on a single version control system. But the debate over it rages on on debian-devel — while Nussbaum argues that the "streamlining" suggestion consists of good ideas that should be considered regardless of what approach the testing/rolling debate settles on in the end.

The proposed approach has its share of critics, including Josselin Mouette, who argued that the proposal does not include enough specific changes to the development process. Mouette believes asking developers to maintain testing/rolling as a usable distribution would require large-scale regression testing "on several upgrade paths" to cope with packages that break when migrating from unstable to testing — for example, packages that break unexpectedly because their dependencies are not listed correctly.

Presumably, then, requiring tighter monitoring of package dependencies would be one of the specific changes Mouette is asking for, but his preferred solution is different entirely: officially adopting one of the existing derivative distributions as a Debian project. By blessing an existing derivative such as Aptosid, he says, the project gains the benefit of their work without requiring any additional outlay of effort from the ranks of current Debian developers. He has also suggested implementing rolling as an Apt suite that interested parties can add on top of testing, which would leave the existing process unchanged.

But the fundamental concern of most who are wary of the proposal is that by putting emphasis on rolling as a second "Debian product," Debian stable will suffer. Part of the concern is that there is just too little developer-power to spread around, but it is also possible that some fans of rolling will stop participating the existing release process for stable, leaving packages untested. Samuel Thibault summed it up nicely, saying he fears "that a lot of developers will see this switching point [unfreezing rolling] as 'ok, now it's debian-release's matter, I can again focus on rolling only'".

Others, like Sean Finney, have argued that the rolling release approach itself is a distraction from the more fundamental problem, which is that during freezes, essentially all work grinds to a complete halt. Rolling releases might help the grinding-to-a-halt problem, Finney said, but they might have no effect at all.

Despite the varying viewpoints, the project as a whole seems to be converging toward a single plan. For his part, Debian Project Leader Stefano Zacchiroli seems generally in support of the rolling idea, but warns that "there might be plenty of lower hanging fruits than a user-targeted testing out there, but for me there is no reason not to discuss other topics as well."

What's next?

All of the interested parties appear to agree on one thing: no matter what proposal reaches consensus through the various mailing list discussion, it can only be tested by being put into practice, and seeing whether or not there is enough developer momentum to see it through.

Case in point: one of the other original Debian CUT approaches focused on building regular "snapshot" releases from testing, thus providing a known-to-be-good entry point for new users. The snapshot project is already underway, and making installable nightly builds as well as regular snapshots available for download. The snapshots do not directly address the same concern as the testing->rolling proposal, but they do meet a need that is not served by the existing development process.

It is a rare case when the vast majority of participants in a large project like Debian agree on the need to undertake a new tactic. There is not universal consensus on the testing->rolling approach yet, but over the past year a rough consensus has emerged that at least something ought to be done to provide a product for users interested in Debian, but requiring fresher package updates than stable (and its multi-year development cycle) can provide.

Nussbaum concludes his post by suggesting that the next step for the project ought to be a GR to measure support for the proposed plan. Zacchiroli indicated that he continues to hear strong support for some form of "user-targeted testing" from the public, but that their preference between CUT, rolling, and simple alterations to the release process remains muddled. He is preparing a user survey to clarify what the end users want. There is no time-frame set for either step at the moment, however, as the discussion continues over on debian-devel.