Log in

No account? Create an account
03 May 2011 @ 01:12 pm
Rolling release  

Since this has been a major request from users for a long time, I can only cool with the idea of seeing the Debian project support a rolling release. However I’m not pleased with the proposed ideas, since they don’t actually include any serious plan to make this happen. Sorry guys, but a big GR that says « We want a pony rolling release to happen » doesn’t achieve anything.

Let me elaborate. First of all, discussions have focused a lot on what to do when we’re in a freeze phase. Numerous cool ideas have been proposed, including PPAs (which again, won’t happen until someone implements them). This is all good, but this is only the tip of the iceberg. Above all, before wondering what can happen in a freeze that lasts 20% of the time, let’s wonder what can happen for the 80% remaining time. Once you have something that works in the regular development phase, you can tune it to make it happen, even if in a less optimal way, when the distribution is frozen. So let’s not put the cart before the horse.

There are three options if you want to make a rolling release happen.

  1. Make unstable usable. to make it happen, you have to prevent the disasters that rarely but unavoidably happen here. You don’t want to make all rolling systems unusable because someone broke grub or uploaded a new version of udev that doesn’t work with the kernel.
  2. Make testing usable. This sounds easy since RC-buggy packages are already prevented from migrating, but actually it is not. A large number of RC bugs are discovered at the time of testing migration, when some packages migrate and others don’t. Worst of all, they require several days to be fixed, and it is very often that they require several months, when one of the packages gets entangled in a transition.
  3. Create a new suite for rolling usage.

The proponents of the CUT project obviously believe in option 2. Unfortunately, I haven’t seen many things that could make it happen. A possible way to fix the situation would be to run large-scale regression testing on several upgrade paths. I don’t know if there are volunteers for this, but that won’t be me. That would also imply to make a lot of important bugs RC, since they could have a major effect on usability, but the release team will not be keen to make it happen.

Because of the testing situation, when someone asks me for a rolling release, I point her to unstable with apt-listbugs. As of today, this is the closest thing we have to a rolling release, so we should probably examine more deeply option 1. Is it that complicated to write a tool to prevent upgrades to broken packages? A 2-day delay in mirror propagation and a simple list of broken packages/versions (like the #debian-devel topic, would be enough. Add an overlay archive, that works like experimental, and you can now handle freezes smoothly. Wait… isn’t that aptosid? We would probably gain a lot of insight from the people who invented this, instead of trying to reinvent the wheel.

Finally, option 3 could open new horizons. There’s a risk that it might drive users away from the testing and unstable suites, and this makes us wonder how we could have proper testing for our packages. Still, build a process that would (and that’s really only an example) freeze unstable every month, give people 10 days to fix the most blatant issues, add a way to make security updates flow in from unstable, and you have a really nice rolling distribution.

So overall, it only requires people to make things happen. You want option 2 to happen? Instead of working on GR drafts, start working with maintainers and release managers on ways to avoid breakage in testing. You want option 3 to happen? Start it as a new .debian.net service and see how it works. Personally, I’d be in favor of offering aptosid developers to become DDs and offer their solution as a Debian service. It would bring in new people rather than driving away existing developers from working on our releases.

(Anonymous) on May 3rd, 2011 09:08 am (UTC)
Don't roll-in the new base system
"because someone broke grub or uploaded a new version of udev that doesn’t work with the kernel"

You need to answer the question of what people wants in a rolling release. Do they want all package to be strictly up to date ? Do they care about that ? Or do they want the latest version of KDE/Gnome/Favorite tool. Personnaly, I think most won't care if they have the latest grub, and if they care, they have unstable for that, and are more likely to accept a small breakage. A good rolling distribution should work like this:

* frequent update of the application, because that is what users want to run as the most up to date

* every year or two, release the new base system, with new version of the kernel, Xorg, grub, ...

The only problem of that scheme is that user also might want to have up to date drivers...


Cyrille Berger
np237np237 on May 3rd, 2011 10:04 am (UTC)
Re: Don't roll-in the new base system
This is the reasoning that leads to backports, and it just doesn’t scale.

Someone wants a new driver. Someone else wants a new KDE. Someone else wants a new PHP. There’s no end to this, and no way to ensure that all combinations work together. Except, of course, using a distribution where we already ensure they do. Like testing or unstable.
Raphaël HertzogRaphaël Hertzog [launchpad.net] on May 3rd, 2011 02:29 pm (UTC)
Care to elaborate what's needed for option 2?
I'm indeed interested in option 2.

I don't really see why you put "large-scale regression testing on upgrade paths" as a precondition. While upgrades to unstable can be difficult at times (like right now with the perl transition), the installability/upgradability of testing is quite good.

Of course some installed packages might be not working due to untested combinations but that's life and real bugs that we want to see reported and fixed. And it's best if Debian maintainers care about those bugs. So it's best if we can endorse this at the project level.

Also what kind of important bugs do we have to raise to RC? Testing is not stable and we don't need the same level of polish at all times...
np237np237 on May 3rd, 2011 02:38 pm (UTC)
Re: Care to elaborate what's needed for option 2?
Testing is always installable. But it is not, by far, always usable.

It happens very often, when we upload a batch of packages for GNOME, that we don’t put tight enough dependencies. Then, one of the packages can migrate to testing in an order we didn’t expect and renders another one unusable. When it happens, you are doomed and you cannot fix it. It is not possible to revert to the previous version, and the new, fixed version with appropriate Breaks or Depends will not migrate to testing until the other package is ready.

This is not a theoretical case; it happened several times in the previous years, each time leaving testing broken for months. We try now hard to schedule transitions better, so chances are that it’s only for weeks. But broken for weeks is not something I expect of a rolling release.

Are you ready to deal with an avalanche of bug reports explaining for months that an important feature doesn’t work, all of them fixed in unstable? Because I am not.
(Anonymous) on May 3rd, 2011 07:58 pm (UTC)
Re: Care to elaborate what's needed for option 2?
I've been running stable on my server, testing on my laptop for about four years now. I started by installing Etch on both machines just after its release, then I upgraded the laptop to Lenny. Is it true that testing is broken for months at a time? Maybe in the sense that you couldn't get a working system if you installed from the servers six months after the last release; but in my experience it works pretty well starting from stable and updating the packages every few days.

Yes, I do get stuck with RC bugs in some packages for an extended period, and I get impatient when a new Gnome version is half-installed (thanks for all your great work, by the way). But I wonder whether the real solution to the problems with testing isn't to improve the transitions.

Would it be possible to calculate the dependencies more automatically? Could some packages be built against testing, to avoid getting tangled in transitions? Would it make sense to decouple architectures for testing, so that a FBTFS for testing-i386 wouldn't stop a successfully built package from making it into testing-amd64? As some people have suggested, maybe some RC bugs should not be released with, but shouldn't block a package from getting into testing outside of a freeze.

I'm not a programmer; I'm not sure what's possible. Renaming testing wouldn't make any difference to me, and the creation of a new rolling suite might or might not improve things. But I think there's been too much emphasis on rolling as a solution to developers being frustrated with the freeze, and not enough attention to the problems users have with testing.

I'm sure Debian will eventually find a good solution.

zwol on May 3rd, 2011 06:26 pm (UTC)
As someone who has been tracking unstable since 1999, I am very much a fan of option 1.

It's my impression that almost all of what you describe as "rare but unavoidable disasters" boil down to "apt decided to delete 200 packages rather than not upgrade 1 package just yet", which is easy enough for a user to block, and could be eliminated with a few tweaks to apt(itude)'s resolver logic. The remainder are "the udev maintainer fucked up AGAIN", which does not have a technical solution.
(Anonymous) on May 3rd, 2011 08:14 pm (UTC)
Option 2 + unstable
What about using testing as a base system and keep unstable in the sources list but with low (like experimental) priority? This will use unstable packages only when are needed.
np237np237 on May 4th, 2011 07:05 am (UTC)
Re: Option 2 + unstable
Yes, but how do users tell which packages they need to grab from unstable? They shouldn’t be supposed to have to deal with that.

Maybe in the end rolling could be an overlay to testing, picking a (sometimes large) set of packages in unstable to make them available to work around problems in testing.

All in all, this might be one of the best ideas proposed.
(Anonymous) on May 3rd, 2011 09:48 pm (UTC)

Prevent something that unavoidably happens? Good luck with that. :-)
(Anonymous) on May 8th, 2011 01:16 pm (UTC)
Would love a Debian rolling release
A rolling and fresh Debian would be wonderful. For some time the Aptosid distribution has satisfied that need for me on my desktop, although SID does break in violent ways from time to time (like right now), and you have to be vigilant to retain a working system. Also to say that Aptosid is not a magic bullet, and lots of things break, so you have to track the upgrade warnings. Having said that - I think the _principle_ of Aptosid works very well.

For me, the ideal Debian desktop system would be:
- Fresh packages, some non-critical bugs acceptable.
- Not frozen at any point, i.e. _true_ rolling.
- No architecture waiting for another.
- No dependency breakage, i.e. _always_ installable/upgradable.

This is currently not satisfied by SID or testing (especially during freeze). I do realize that it's a tall order, but I also believe it's within reach. Maybe best served by a repository between testing and unstable, with some added rules. So, something like:

Experimental (as today) -> Unstable (as today) -> Rolling (no dep.breakage+no critical bugs) -> Testing (as today) -> Stable (as today)

But I'm probably just naive....
(Anonymous) on June 20th, 2011 07:29 pm (UTC)
thats beyond question charming of you
here is some of the outwit youtube movies i gnome more barest unflappable hotels i visited in

[url=http://www.youtube.com/watch?v=EhAhMVuByc8]מלון דן פנורמה אילת[/url]]
[url=http://www.youtube.com/watch?v=npeF6e84Y-I]מלון שרתון אילת[/url]]
[url=http://www.youtube.com/watch?v=kyFginpnOlQ]מלון המלך דוד ירושלים[/url]]
[url=http://www.youtube.com/watch?v=W26aBZbq5LQ]מלון רימונים נווה אטיב[/url]]

if you are looking in return guest-house for the benefit of your next false step, that can be a great elucidation for you