I'll miss the bi-yearly fun with trying out a new release, and the name alliteration, but I think overall it's a smart move for Ubuntu. Does anyone have any reasons why they shouldn't move toward this? I'm curious.
A lot of the counter argument is based on FUD and bad experiences with OTHER rolling release distros. I'm not sure we can look at Gentoo or Arch as examples of what Ubuntu would be aiming to do (and I say this as an Arch user).
Within the proposal, it states that packages would be released when ready, and when stable. This doesn't mean that you are going to live on the bleeding edge like an Arch or Gentoo user may. You're going to get the updates after Ubuntu has done QA on them, and the maintainer will probably be peeking at bug trackers on other distros for tips on issues (Arch and Gentoo effectively expand their QA process).
It is true that there will probably be periodic UI changes in some of the applications. It is not necessarily true that these changes will happen any more frequently than they do now (since each application has different life cycles). What will happen is you will potentially not need to wait 6+ months to get a new version of a package with a fix or improvement that is important to you.
If it lets them spend more time on QA and development rather than arbitrary deadlines and bundling, this sounds like a win-win to me. If and when problems happen, they'll get it figured out and hopefully not repeat their mistakes.
I don't think it's so much on the bleeding edge in Arch as most people think and packages are usually upgraded in such a way so that dependencies don't cause problems in other packages (at least from my experience). The key has always been to always do a system upgrade and not upgrade individual packages, i.e. always run pacman -Syu or pacman -Syu <packagename>. In four years I've never seen anything break (knock on wood) aside from a minor issue with a pcre upgrade sometime ago. That has just been my experience though, I run Arch on my desktop, laptop and about 10 vps servers.
4. Learn that I shouldn't have run pacman just then, and now I have to follow these steps to un-break my system
The most notable instance was when Arch decided that /usr/lib should be a symlink to /lib. Yeah, barely recovered from that... it was also a reinforcement of my position that basic utilities should be statically linked.
I finally gave up on Arch when a GRUB update broke my system and locked me out of my encrypted root.
Yeah I got caught by forcing the /usr/lib update too. Went away for a month, came back and did a full upgrade, failed. Checked the website, the news had dropped of the front page, forced update, broke it horribly.
Despite the problems, I still find rolling release vastly preferable. If Ubuntu can bring some of the commercial support quality to a rolling release, they'd alleviate a lot of the difficulties that I have with Arch.
Arch is very good if you run it as your main system and keep it updated very frequently. Forget it for six months (because it's an unused multiboot, or whatever) and try to do an upgrade, and it might be more painful.
I got burnt by the glibc mess last summer, where you had to run a specific set of --force things in a given order to get through and if you didn't, well, you lost your /lib (at which point it's game over, since freaking pacman isn't statically linked).
Response in forums or irc (I don't remember) was "It's rolling release, you had three whole months to update, too bad for you".
Atomic releases avoid the problem because everyone will do this kind of breaking changes at the same point, whereas with rolling releases, you can't force people to update all at the same time, so you'll always end up losing people, once your migration path inevitably becomes invalid because of the way everything goes forward.
Couldn't you solve that problem with some type of repository snapshoting/versioning. So if you try to update more than, say, 1 month, the system installs the updates incrementally.
Arch has been overall very good for me, but there have been breakages (and I experienced a whole lot more with Gentoo, though that was a while ago). Arch's systemd migration in particular was somewhat painful and the documentation wasn't great for the process (it has improved somewhat since). I seriously doubt that Ubuntu would expect their users to do what I had to do to apply that update (since Arch and Ubuntu serve very different target audiences). This is no knock on Arch, their approach is appropriate for their audience.
Because Ubuntu serves such a different target audience, I expect the whole update process will be more hands-free and possibly a little more smooth. Their mission is "Linux for Human Beings" instead of "Linux for hackers and enthusiasts", so this is a necessity.
> I expect the whole update process will be more hands-free and possibly a little more smooth.
I've been using my current Arch install as my main desktop since the great systemd switch late last year, and I just have it do an apper autoupdate on Sundays. I don't even do pacman -Syu, I just check the logs after an update before a restart to make sure it went smoothly.
It kind of won me over, that and yaourt at least. I have Ubuntu on my grandparents machine and sshing into it and using apt starts to feel last century after getting used to pacman.
1. They could underestimate the effort needed. Continously integrating the packages from sid and upstream and the own development effort, all without breaking for the user, without having targeted maintainers per package, is quite an effort.
The mechanisms Gentoo has in place to manage this don't seem fitting for Ubuntu.
2. The half-year release circle gives users a sense of the progress made. Even while using a LTS-release, observing the new releases i can see where Ubuntu is heading to, what is changing and what to expect for the next LTS. The releases give Ubuntu opportunity to talk about their changes.
Not saying it can't work or it is a bad idea (I don't have enough experience maintaining, especially not a distro, to judge). I see the positive aspects and the proposal sounds reasonable.
The packaging is actually likely to be a lot easier, which is one of the big perks to this model. They only get stuck supporting the LTS releases, instead of having to backport fixes to every release in the last X years (was it 4?).
Something to keep in mind is that just because there is an updated package available for something, there is no need to get it updated on day 1. I suspect they've got a good feel for update frequency and priority on various packages. Worse case, they'll probably get it updated and more recent than the six month cycle (or 12 month if you run LTS).
If major changes (like dumping Gnome for Unity) get triggered by the same button as security patches etc users might be reluctant to press that button.
And if there's a major change and some users decide to wait before upgrading (while the bugs get ironed out) it's easier to support them if they all wait at the same version.
