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.
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'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. Run pacman -Syu
2. Pacman failed.
3. Go to Arch website
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.
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.
That's the number one thing to remember with pacman, _never_ force an update. That is how 90% [citation needed] of problems arise.
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.
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.
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).
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.