A concrete proposal for rolling implementation
Hi,
during the recent discussions about rolling, a proposal was made in a
blog comment, and after giving it some quick thoughts, most people I’ve
talked with seem to think it is a good idea, so it’s time for it to be
discussed at large.
It starts from the following fact: if you want a testing system that
works correctly, you usually have to add APT lines for unstable, while
pinning them to only install specific packages you need to unbreak
what’s broken in unstable.
The idea is to make this process automatic. Let me elaborate.
The new “rolling” suite
-----------------------
This would be a pseudo-suite, like experimental. Except that while
experimental is built on top of unstable and filled manually by
maintainers, rolling would be built on top of testing and filled
semi-automatically. A rolling system would have typically 2 APT lines:
one for testing and one for rolling.
The rolling suite would only exist for a subset of architectures (we
could start with powerpc, i386 and amd64), generated by picking up
packages from unstable. Typically it would be generated from an override
file that looks like:
source-package version
xserver-xorg-video-ati 1.2.3-4
...
The rolling suite would try to have a package that has *at least* this
version. If it is found in testing, the package is removed from rolling.
If otherwise it is found in unstable, the package is picked from
unstable.
This way, when something is broken in testing and cannot be unbroken
quickly, a maintainer who notices it could add (or make the people in
charge add) the necessary packages to the override file. If, for a
reason or another, an important bug fix or a security update doesn’t
propagate to testing quickly enough, you can now just add it and the
necessary dependencies to rolling, and people using it aren’t affected.
Whenever the affected packages finally migrate to testing, the
discrepancy between rolling and testing automatically disappears.
The reason for the “at least” version rule is that new uploads to
unstable are supposed to fix the situation in testing anyway. I don’t
think we should keep in rolling packages that are no longer in unstable.
A concrete example
------------------
Let’s imagine something that might happen soon (although of course we
will try hard for it not to happen): a new version of nautilus migrates
to testing, but it was missing a Breaks - it doesn’t work with the
version of gnome-settings-daemon in testing. The new
gnome-settings-daemon in unstable works, but it won’t migrate because
there is a libgnomekbd transition in progress, and gnome-screensaver
which is part of the transition doesn’t build on s390.
In this case, we can just add libgnomekbd and gnome-settings-daemon to
the override file. Users of the rolling suite will have the two versions
of libgnomekbd available, and they can update their systems to a working
state.
Why I like it
-------------
First of all, this idea doesn’t affect *at all* the current release
process. It just takes people willing to maintain the override file -
and we could even choose to let any DD modify it. And it’s much faster
to modify such a file than telling every user from testing that they
have to upgrade to the unstable version.
And just as importantly, I think it should just work. There’s very
little chance that people get completely hosed systems like it happens
sometimes for unstable. There are all chances that something broken in
testing can be fixed by pulling a handful of packages from unstable.
What to do during freezes
-------------------------
I’m not sure we really need to do something different in times of
freeze. Our time would be better spent by reducing the freeze time and
making it more predictable; squeeze has been an awesome step in this
direction.
If we want to do something different though, there is a simple recipe:
allow packages to be picked up from unstable, but also from
experimental. Again, no disruption: people can keep on breaking some
pieces of experimental, but if they want some other pieces to be useful
for rolling users, they just need to be committed to more carefulness
and to add them to the override file.
What do you think?
--
Joss
Reply to: