A constantly usable testing distribution for Debian

Debian's "testing" distribution is where Debian developers prepare the next stable distribution. While this is still its main purpose, many users have adopted this version of Debian because it offers them a good trade-off between stability and freshness. But there are downsides to using the testing distribution, so the "Constantly Usable Testing" (CUT) project aims to reduce or eliminate those downsides.

About Debian unstable & testing

Debian "unstable" is the distribution where developers upload new versions of their packages. But, frequently some packages are not installable from unstable due to changes in other packages or transitions in libraries that have not yet been completed.

Debian testing, on the contrary, is managed by a tool that ensures the consistency of the whole distribution: it picks updates from unstable only if the package has been tested enough (10 days usually), is free of new release-critical bugs, is available on all supported architectures, and it doesn't break any other package already present in testing. The release team controls this tool and provides "hints" to help it find a set of packages that can flow from unstable to testing.

Those rules also ensure that the packages that flow into testing are reasonably free of show-stopper bugs (like a system that doesn't boot, or X that doesn't work at all). This makes it very attractive to users who like to regularly get new upstream versions of their software without dealing with the biggest problems associated with them. That is very attractive to users, yet several Debian developers advise people to not use testing. Why is that?

Known problems with testing

Disappearing software: The release team uses the distribution to prepare the next stable release and from time to time they remove packages from it. That is done either to ensure that other packages can migrate from unstable to testing, or because a package has long-standing release-critical bugs without progress towards a resolution. The team will also remove packages on request if the maintainers believe that the current version of the software cannot be supported (security-wise) for 2 years or more. The security team also regularly issues such requests.

Long delays for security and important fixes: Despite the 10-day delay in unstable, there are always some annoying bugs (and security bugs are no exceptions) that are only discovered when the package has already migrated to testing. The maintainer might be quick to upload a fixed package in unstable, and might even raise the urgency to allow the package to migrate sooner, but if the packages get entangled in a large ongoing transition, it will not migrate before the transition is completed. Sometimes it can take weeks for that to happen.

The delay can be avoided by doing direct uploads to testing (through testing-proposed-updates) but that mechanism is almost never used except during a freeze, where targeted bug fixes are the norm.

Not always installable: With testing evolving daily, updates sometimes break the last installation images available (in particular netboot images that get everything from the network). The debian-installer (d-i) packages are usually quickly fixed but they don't move to testing automatically because the new combination of d-i packages has not necessarily been validated yet. Colin Watson sums up the problem:

CUT's history

CUT has its roots in an old proposal by Joey Hess. That introduces the idea that the stable release is not Debian's sole product and that testing could become—with some work—a suitable choice for end-users. Nobody took on that work and there has been no visible progress in the last 3 years.

But recently Joey brought up CUT again on the debian-devel mailing list and Stefano Zacchiroli (the Debian project leader) challenged him to setup a BoF on CUT for Debconf10. It turned out to be one of the most heavily attended BoFs (video recording is here), so there is clearly a lot of interest in the topic. There's now a dedicated wiki and an Alioth project with a mailing list.

The ideas behind CUT

Regular snapshots of testing

There's general agreement that regular snapshots of testing are required: it's the only way to ensure that the generated installation media will continue to work until the next snapshot. If tests of the snapshot do not reveal any major problems, then it becomes the latest "cut". For clarity, the official codename would be date based: e.g. "cut-2010-09" would be the cut taken during September 2010.

While the frequency has not been fixed yet, the goal is clearly to be on the aggressive side: at the very least every 6 months, but every month has been suggested as well. In order to reach a decision, many aspects have to be balanced.

One of them (and possibly the most important) is the security support. Given that the security team is already overworked, it's difficult to put more work on their shoulders by declaring that cuts will be supported like any stable release. No official security support sounds bad but it's not necessarily so problematic as one might imagine. Testing's security record is generally better than stable's is (see the security tracker) because fixes flow in naturally with new upstream versions. Stable still get fixes for very important security issues earlier than testing, but on the whole there are fewer known security-related problems in testing than in stable.

Since it's only a question of time until the fixed version comes naturally from upstream, more frequent cut releases means that users get security fixes sooner. But Stefan Fritsch, who used to be involved in the Debian testing security team, has also experienced the downside for anyone who tries to contribute security updates:

So if it's difficult to form a dedicated security team, the work of providing security updates must be done by the package maintainer. They are usually quite quick to upload fixed packages in unstable but tend to not monitor whether the packages migrate to testing. They can't be blamed for that because testing was created to prepare the next stable release and there is thus no urgency to get the fix in as long as it makes it before the release.

CUT can help in this regard precisely because it changes this assumption: there will be users of the testing packages and they deserve to get security fixes much like the stable users.

Another aspect to consider when picking a release frequency is the amount of associated work that comes with any official release: testing upgrades from the previous version, writing release notes, and preparing installation images. It seems difficult to do this every month. With this frequency it's also impossible to have a new major kernel release for each cut (since they tend to come out only every 2 to 3 months) and the new hardware support that it brings is something worthwhile to many users.

In summary, regular snapshots address the "not always installable" problem and may change the perception of maintainers toward testing so that hopefully they care more of security updates in that distribution (and in cuts). But it does not solve the problem of disappearing packages. Something else is needed to fix that problem.

A new "rolling" distribution?

Lucas Nussbaum pointed out that regular snapshots of Debian is not really a new concept:

In Lucas's eyes, CUT becomes interesting if it can provide a rolling distribution (like testing) with a "constant flux of new upstream releases". For him, that would be "something quite unique in the Free Software world". The snapshots would be used as starting point for the initial installation, but the installed system would point to the rolling distribution and users would then upgrade as often as they want. In this scenario, security support for the snapshots is not so important, what matters is the state of the rolling distribution.

If testing were used as the rolling distribution, the problem of disappearing packages would not be fixed. But that could be solved with a new rolling distribution that would work like testing but with adapted rules, and the cuts would then be snapshots of rolling instead of testing. The basic proposal is to make a copy of testing and to re-add the packages which have been removed because they are not suited for a long term release while they are perfectly acceptable for a constantly updated release (the most recent example being Chromium).

Then it's possible to go one step further: during a freeze, testing is no longer automatically updated, which makes it inappropriate to feed the rolling distribution. That's why rolling would be reconfigured to grab updates from unstable (but using the same rules as testing).

Given the frequent releases, it's likely that only a subset of architectures would be officially supported. This is not a real problem because the users who want bleeding edge software tend to be desktop users on mainly i386/amd64 (and maybe armel for tablets and similar mobile products). This choice—if made—opens up the door to even more possibilities: if rolling is configured exactly like testing but with only a subset of the architectures, it's likely that some packages would migrate to rolling before testing where non-mainstream architectures are lagging in terms of auto-building (or have toolchain problems).

While being ahead of testing can be positive for the users, it's also problematic on several levels. First, managing rolling becomes much more complicated because the transition management work done by the release team can't be reused as-is. Then it introduces competition between both distributions which can make it more difficult to get a stable release out, for example if maintainers stop caring about the migration to testing because the migration to rolling has been completed.

The rolling distribution is certainly a good idea but the rules governing it must be designed to avoid any conflict with the process of releasing a stable distribution. Lastly, the mere existence of rolling would finally fix the marketing problem plaguing testing: the name "rolling" does not suggest that the software is not yet ready for prime time.

Conclusion

Whether CUT will be implemented remains to be seen, but it's off for a good start: ftpmaster Joerg Jaspert said that the new archive server can cope with a new distribution, and there's now a proposal shaping up. It may get going quickly as there is already an implementation plan for the snapshot side of the project. The rolling distribution can always be introduced later, once it is ready. Both approaches can complement each other and provide something useful to different kind of users.

The global proposal is certainly appealing: it would address the concerns of obsolescence of Debian's stable release by making intermediary releases. Anyone needing something more recent for hardware support can start by installing a cut and follow the subsequent releases until the next stable version. And users who always want the latest version of all software could use rolling after having installed a cut.

From a user point of view, there are similarities with the mix of normal and long-term releases of Ubuntu. But from the development side, the process followed would be quite different, and the constraints imposed by having a constantly usable distribution are stronger. With CUT, any wide-scale change must be designed in a way that it can happen progressively in a transparent manner for users.