Though at this point I would just settle for getting back a PPA for proprietary video drivers.
Thankfully, if you read the mailing list thread deeply enough, the Tech Architect for Canonical came along and applied a bit of common sense to this whole "rolling release cuz its teh l33tn3ss lolz. do it NOW!" crowd. If they do eventually go rolling release, it would hopefully be done in a far more sensible way than distros like Arch, that are broken and buggy as the filthy kids' hair much of the time.
Personally I'm no fan of therolling release model. And yes, I've used rolling release before and been less than impressed. I've used Linux exclusively since '95 and had experience with a bit of everything, including long enough stints with both Arch and Gentoo. Long enough to know that I won't be using a rolling release on any of my machines.
I think that this discussion lack a definition of what a rolling release is. The way I see it is that a rolling release means updated packages are pushed to users when a new version is available, period.
Thus, if I understand it correctly, a rolling release may be bleeding edge pushing early alpha packages or may be very conservative only pushing thourougly tested stable versions. The difference from what is done today is simply that the users get each individual package when it is released, and not in a pre-specified date in time when the whole system is updated. So if the packages pushed will be more or less bleeding edge than what it is today is probably a completely different discussion.
From what I've gathered from the mailing list, the main problem is not really with stability, but with support. How to support a moving target?
Having said that, my opinion is that the best model has already been nailed by Windows/MacOSX/Android/iOS etc. Core components of the OS remain stable in order to provide a stable target for developers while other things are updated (no need to wait for the next version of the OS to get updated XBMC or LO). Basically, everything that breaks compatibility at any level, should only be implemented into the next version of the OS, while other updates, bugfixes and security patches should be pushed asap. The problem is that this would require a lot of additional work from canonical in order to backport everything to the stable branch.
PPAs are not a proper solution because users must decide by themselves which one to trust or not.
As always, feel free to correct me.
I do not know how Ubuntu wants to do it.
OpenSUSE has a rolling release. ( two versions actually )
It offers the latest stable packages, and is updated more often then the normal releases, like 12.1 12.2 12.3.
There is also a factory version, latest software, kind of bleeding edge version.
The Tumbleweed project provides a rolling updates version of openSUSE containing the latest stable versions of all software instead of relying on rigid periodic release cycles. The project does this for users that want the newest, but stable software.
The difference to Factory is that Factory is bleeding edge, often experimental, not yet stabilized software that needs more work to become useful. Tumbleweed contains the latest stable applications and is ready for daily use.
IME, all Ubuntu upgrades, including distribution version upgrades, have worked without borking the system for years. I don't see how rolling release would change that.
It works because the whole industry targets single OS so all big new hardware and software features come at same time with the new version of OS.
Rolling release model is better if interfaces and libraries are properly versioned and treated with care.
That said, it's true Arch does sometimes require it's users to do advanced things (cause it's designed for advanced users), but that's only because they'd rather make changes faster (leaving the details up to the users) instead of writing scripts to automate all the conditions. That doesn't mean that Ubuntu (or other user-friendly distros) couldn't hold off on releasing core changes until the proper automation scripts had been written and fully tested. Since these changes are part of the system core, you probably want to lag their release farther behind anyways (to catch more bugs), and they wouldn't really effect user-applications like Office, Gimp, Inkscape, Blender, etc.. all those could still be released "day of" without any problems.
Look at Chakra's Half-rolling release model: http://chakra-linux.org/wiki/index.p..._Release_Model
This is exactly the kind of release model Ubuntu should adopt: Stable core, Bleeding apps.