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 this distribution
and the Constantly Usable Testing (CUT) project aims to resolve those.
This article will present the project and the challenges involved to make
it happen.
About Debian unstable & testing
Debian unstable is the distribution where developers upload new versions of
their packages. It happens frequently that some packages are not installable due
to changes in other packages or due to transitions not yet 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 enough tested (10 days usually), if it s free of new
release-critical bugs, if it s available on all supported architectures, and if
it doesn t break any other package already present in testing. The Release
Team (RT) controls this tool and provide 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 to them. This is all very
attractive, yet several Debian developers advise people to not use
testing. Why is that?
Known problems with testing
Disappearing software
The release team use this distribution to prepare the next
stable release and from time to time they remove packages from it. Either
because it s needed to ensure that other packages can migrate from
unstable to testing, or because they have long-standing release-critical
bugs without progress towards a resolution. It also happens that they
remove packages on request of the maintainers because they 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 already has 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 gets entangled in a
large ongoing transition, it will not migrate before the transition is
completed. Sometimes it can take weeks for that to happen.
This delay can be avoided by doing direct uploads to testing (through
testing-proposed-updates) but this is almost never used, except
during a freeze, where targeted bugfixes 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:
Getting new installer code into testing takes too long, and problems
remain unfixed in testing for too long. [...] The problem with d-i
development at the moment is more that we re very slow at producing new
d-i *releases*. [...] Your choices right now are to work with stable (too
old), testing (would be nice except for the way sometimes it breaks and
then it tends to take a week to fix anything), unstable (breaks all the
time).
CUT s history
CUT finds its root in an old
proposal by Joey
Hess: it 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 was 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 BoF (video recording is
here),
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 rest of this article tries to summarize the various options
discussed and how they re supposed to address the problems identified.
The ideas behind CUT
Among all the ideas, there are two main approaches that have been
discussed. The first is to regularly snapshot testing at points where it
is known to work reasonably well (those snapshots would be named cut ).
The second is to build an improved testing distribution tailored to the
needs of users who want a working distribution with daily updates, its
name would be rolling .
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 problem, 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 one (see
the
security tracker) because
fixes flow in naturally with new upstream versions. Stable still get fixes
for very important security issues sooner than testing, but on the whole
there are less 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:
The updates to testing-security usually stay useful only for a few weeks, until
a fixed version migrates from unstable. In stable, the updates stay around for
a few years, which gives a higher motivation to spend time on preparing them.
So if it s difficult to form a dedicated security team, the work of
providing security updates comes back to 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 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 changes the perception of maintainers towards testing, so that hopefully
they care more of security updates in that distribution (and in cuts).
But they do 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:
How would this differentiate from other distributions doing 6-month
release cycles, and in particular Ubuntu, which can already be seen as
Debian snapshots (+ added value)?
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. That s why there have been discussions of introducing a
new distribution named rolling 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 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 than 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 tends 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 migrate to rolling before
testing when 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 of the migration to testing
once 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. The project might start quickly: 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 every software could use rolling after having installed a
cut.
From a user point of view, there are similarities with the mix of usual
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: any wide-scale change must be
designed in a way that it can happen progressively in a transparent manner for
the user.
This article was first published in Linux Weekly News. If you want to see more articles like this, join Flattr and click on the flattr button below every article that you like.
21 comments Support my work