

Ubuntu Rolling Release Proposal - hotice
https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036537.html

======
moxie
What's interesting is that they are in part re-creating the original problem
they were trying to solve.

The complaints about Debian were that they only cut a release like every two
years. The Debian response was that people who wanted more timely updates
could run the "testing" branch, which was a "rolling" release.

Ubuntu promised to solve the slow release cycles and the instability of a
rolling branch by cutting stable and well-composed releases on a rigorous six
month schedule.

This announcement sounds a lot like the original Debian model they were trying
to get away from.

~~~
gizmo686
A difference is that Debians testing branch was a testing branch, and as such
did not have the same effort and priority put in to keeping it stable. Even as
a rolling release, I would expect Ubuntu's main reopositories to be more
stable than debian tesdting.

~~~
meaty
From extensive experience, debian testing is way more stable than Ubuntu's
current LTS release even.

~~~
BUGHUNTER
I would like to learn from others: how do you handle security with testing? I
like debian testing very much, and occassionally I have the idea of using this
in production, too, but I fear the responsibility to take care of many
security fixes on my own. here are the high-urgency vulnarable sources for
testing:

[https://security-
tracker.debian.org/tracker/status/release/t...](https://security-
tracker.debian.org/tracker/status/release/testing?show_high_urgency=1)

but even more surprisingly, this list for stable is even longer:

[https://security-
tracker.debian.org/tracker/status/release/s...](https://security-
tracker.debian.org/tracker/status/release/stable?show_high_urgency=1)

Can anybody explain this?

(Yes, I will take the shame on me and ask this on a debian mailing list,
however, maybe anybody has a good explanation here...)

~~~
meaty
As follows:

1\. Read the vulnerability description.

2\. Ask yourself if you are vulnerable.

3\. No? Don't worry about it.

4\. Yes? External mitigation where possible or patch ourselves and commit back
to debian (we a project member on our team).

We've not got to 4 yet, but have committed loads of fixes anyway.

~~~
BUGHUNTER
OK, but real life (low budget) scenario is:

1\. aptitude update && aptitude upgrade 2\. ask yourself, if your system is
vulnerable now 3\. feel the good hope and go ahead.

If I had the budget / time to research every single CVE I would probably not
trust repositories at all...

do YOU trust repositories?

~~~
meaty
Yeah and that's pretty much good enough for most people.

That's what we do for our internal dev systems.

------
mhw
I think that's a very well reasoned proposal and I'd be very happy to see it
implemented. I might be unusual, but I find myself in both of the user groups
that the proposal identifies. For my 'utility' machines (home server, XBMC
host, web servers) I prefer the stability of the LTS series, but for my laptop
I'm happy to trade that stability for getting new stuff sooner, particularly
new usability features that are getting baked into Unity and other components.

One minor nit: in the section on benefits for Core/MOTU developers it suggests
that only 2 releases would need to be supported. I think in reality that would
actually be 4 releases, as with a 5 year support commitment for each LTS
release there could be up to 3 LTS releases that are still being supported at
any point in time. May be just a minor wording thing though - I'm sure the
author knows what he's talking about.

~~~
icebraining
Your use case is exactly what many of us Debian users have been doing for a
long time. I use Unstable on my laptop and Stable (+ backports) on my VPS for
those exact reasons.

~~~
takluyver
Technically, Debian unstable is close to what I want, but I don't want to be
using something that comes with 'at your own risk' warnings day to day.

I think the expectation is the important thing: if an update breaks something,
the response I want to see is 'sorry, we'll fix that ASAP and try to avoid
doing it again'. I get the impression that Debian unstable (and to a lesser
extent testing) is only intended for people who're willing to put up with
things breaking often.

~~~
icebraining
Well, yes, it comes with absolutely no guarantees. That said, many Debian
developers use it, and breakages have been rare at least for the last few
years, since I started using it.

------
homeomorphic
I'm sure the decision wasn't taken lightly, and I'm sure Canonical has
concluded that an 18 month LTS + rolling makes the most sense for the project.
As a user, I am a bit worried about rolling releases though. Maybe someone
here can alleviate my worries?

As I see it, software has to change. The question for distros is just _when?_
A rolling distro sees such changes continuously, and each package may in
principle change at any point independently of any other package. Doesn't that
mean that at any point, my workflow-critical programs may change their
behavior or even stop working together? Sure, I can do upgrades more seldomly,
but then I'm left without security updates. The main benefit I feel that non-
rolling distros offer is _predefined breakage points_. I know that Ubuntu
Quantal will work the way it works now until I upgrade to the next release.
Even simply knowing in what way software _is_ (and will remain) broken is
useful.

Now of course, one can stay with LTS and get the same behavior. I guess I'm
simply complaining because the 6 month cycle was perfect for me.

At any rate, I would guess that most users only really desire rolling behavior
for a few (dozens?) of packages. Ubuntu has that nicely covered with PPAs (and
also "special status" rolling packages like Firefox).

~~~
YokoZar
The decision hasn't been made yet. Canonical's CTO may have decided he likes
it, but the Ubuntu project hasn't yet given it a pass.

If you've got workflow-critical programs you don't want updating, use the LTS
release. That's what it's for.

~~~
pyre
I think the real issue is when infrastructure things move.

How would the move to PulseAudio have worked in a rolling release? Would
someone with a new install end up with PulseAudio, but someone with an
existing install, would just never have it installed unless they knew what it
was and started poking around for it?

The same for the transition to using evdev for (e.g.) mouse-handling in X.org
rather than defining things in xorg.conf.

I know that Debian has lived through these transitions, but my impression was
that the packages were setup in a way that allowed people to keep the old
config, or move to the new one. That said, it seems like these issues could be
more complex than a 'human being' (Ubuntu's target market) would be able to
decipher.

~~~
YokoZar
It's not even clear that the rolling release will be intended for non-
enthusiasts at this point, however as a matter of policy you can be pretty
sure that any update applied to the rolling release will need to be tested
against users as old as the last LTS.

That means the same sort of transition of config files and libraries that
occur on release upgrade would just happen during a normal package install,
which is pretty much how it works anyway (a release upgrade isn't much more
than a giant group of packages being upgraded together -- all this logic is
stored in the packages themselves).

~~~
pyre
I get the difference between a release upgrade and a rolling release schedule.
My point was that when you are creating a release, you can say "this is the
point where this change happens." With a rolling release, will a "apt-get
upgrade" transition me? What if this was unexpected? What if this breaks my
config?

For most normal upgrades this doesn't matter because the applications are
usually fairly insular, but when you get into integrated systems like Desktop
Environments it's different. Especially when Ubuntu is making a number of
UI/etc changes to the desktop. It would be a bit surprising to have UI parts
shift around. When you do a release upgrade, you know that there are going to
be some major changes, and there are ChangeLog/notes on the release itself to
tell you what major changes there are.

------
hristov
This repeated notion of a truly converged OS is really annoying and it is very
disappointing to see Ubuntu continue to pursue it despite the loud complaints
of most of their users.

Lets point out the obvious: the user interaction of a small handheld device is
very different than that of a computer with a full size monitor and mouse.
Thus any os's on those two devices have to have different UI features. That's
it.

Of course the parts of the OS that are not UI can be converged. In that sense
Linux is already a fully converged OS.

But you are never going to fully converge the UI of two devices that use
vastly different UI methods.

~~~
Recoil42
>Lets point out the obvious: the user interaction of a small handheld device
is very different than that of a computer with a full size monitor and mouse.

And what happens in-between? What happens in the case of tablets? Notebooks
with a touchscreen? Future devices like large format displays with full UI,
and future paradigms like gesture control?

~~~
kinleyd
At this stage the key differentiation point is touch (ie. your finger as the
pointer) v. the pointer (mice/keyboard, etc.) The UI for these two categories
is naturally different, and convergence would be possible only when the UI can
handle both. Even in the case of notebooks with touchscreens, the UI has to
handle both requirements well, that of the finger and of the mouse/keypad. I
personally feel Ubuntu is neglecting the latter. In time, that may well be the
right choice. At present, it's definitely only part of the story.

------
jjcm
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.

~~~
gtaylor
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.

~~~
yogo
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.

~~~
jff
My experience with Arch has frequently been:

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.

~~~
adwf
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.

~~~
deepdog
> forcing the /usr/lib update

That's the number one thing to remember with pacman, _never_ force an update.
That is how 90% [citation needed] of problems arise.

------
ohazi
I definitely support this. Having a rolling release was the primary reason why
I decided to go with debian (unstable) vs (x)ubuntu a few weeks ago. My
previous install (oneiric; non-LTS) was about to become unsupported, and the
last time I decided to ignore the official support status (years ago... I
think it was dapper?), the main repository upped and vanished one day. That
was not a fun morning.

~~~
IgorPartola
The problem is that Debian can be faster or slower whilst Ubuntu LTS releases
are on a schedule. For example I believe the currently stable Debian release
includes Python 2.6 because 2.7 just missed it. I prefer Ubuntu's LTS releases
to Debian because they are predictable.

~~~
ohazi
Yes, I agree that ubuntu's time based releases are generally a better
experience that debian's "whenever it's ready" stable releases. Debian's
testing and unstable branches are rolling releases though, and those were the
only alternatives I was actually considering.

~~~
gtaylor
Although, I'm not sure we can even look at the Debian when trying to predict
what a rolling release Ubuntu would look like (even considering that they are
"relatives").

The current difference in manpower and mind share is pretty big between these
two related distros. Regardless of which one each of us may like better,
Canonical has the manpower and mindshare to probably have a bit more success
with this model. I really like Debian, so this is not a knock on them (I used
Debian on servers for a very long time with great results).

Heck, we may even see Debian and Ubuntu working more closely once they take on
this shared dev style (I know, I am pipedreaming, but hey...).

~~~
IgorPartola
I was under the impression that the Debian team is much larger than
Cannonical. This is why they have always said that they could not do what they
do without Debian. The biggest problem with a rolling release is that you
constantly have to reboot the server to apply kernel upgrades, which you have
to do less with LTS (though the first 6 months after the release it feels like
a weekly chore).

~~~
gizmo686
Doesn't Linux support hotswapping kernels?

~~~
IgorPartola
Ksplice [1] lets you do that. For a while they had very limited support for
it, but I just checked and they seem to support Ubuntu on the desktop as well
[2]. Once this comes to the server edition and/or is bundled by Canonical,
using Ubuntu would become much smoother.

[1] <http://www.ksplice.com/>

[2] <http://www.ksplice.com/uptrack/download-ubuntu>

------
loudmax
I suppose derivative distros like Xubuntu and Edubuntu will need to follow
suit.

I've had pretty bad experiences with non-LTS versions of Xubuntu. The last
time I had a go on it on my laptop, things broke unpredictably, a little at a
time. When I say unpredictably, I mean totally by surprise, not even after
performing an update. First, Pulse audio stopped working. Spent a few days
trying to fix it, then gave up and reverted to Alsa. Then the graphical login
got stuck in an endless loop cycle. So reverted to text login, starting X
manually after I'd log in. When wireless stopped working, I gave up. I run the
LTS Xubuntu on two other machines and neither of them have had problems like
this. I put my laptop on the LTS Xubuntu and it's been good since.

I'm guessing mainstream Ubuntu gets more QA and is more stable than Xubuntu.
It might be harder for derivative distros to keep up with a rolling release.
Or maybe not... this might give them more flexibility to QA stuff as needed
instead of trying to keep up with a new release every six months. As long as
Cannonical keeps the LTS cycle going, moving to a rolling release sounds
reasonable.

~~~
bad_user
One thing to keep in mind is that you're going to have far fewer problems with
compatible hardware.

On my older laptop things were breaking on each upgrade. Most problems I had
were with the Geforce graphics card included, but wireless stopped working at
some point in combination with the router that I have at home (kept working
with other routers just fine, so I guess it was a protocol issue). Anyway, it
required constant tinkering.

So first of all, on that laptop I gave up on Nvidia's proprietary drivers and
went with Nouveau, which for my needs works well. 90% of all problems I ever
had were linked to these proprietary Nvidia drivers. Don't know how well
Nouveau works with newer Geforce cards, but you should give it a try.

I also have a new Thinkpad with Intel HD 4000 graphics and the Wifi chip is
also from Intel. I rejected other models with Geforce cards on purpose. With
the latest Ubuntu everything worked flawlessly out of the box on this laptop,
graphics, wifi, sound, everything.

People expect Linux distros to run well on any hardware they throw at it and
many times it does, but if you're buying a new laptop / PC, do some research
first and prefer models for which all drivers are available as open-source, or
if you don't want that hassle, search for models certified for Linux.
Thinkpads are good (if you get it with Intel HD at least), Dell also sells a
couple of models that are Ubuntu-certified, like that new developer-targeted
laptop, there's also System76 and I'm sure you can find others.

------
zalew
considering the tipping point of me leaving buntu was being tired of the
upbreak release process, I second this idea.

they are basically adopting the debian scheme, only the stable releases will
be more frequent.

~~~
csense
I thought Ubuntu's original reason for existing was because Debian releases
don't happen often enough?

~~~
zanny
It existed because testing wasn't stable enough and stable wasn't fast enough.
The 2 year LTS releases are basically just the slow stable thing carried over,
but having 2 layers of rolling release (like Arch) where you have a base repo
and a testing repo lets them having the rolling release without all the
continuous integration problems if it hits enough testing users first.

------
eliben
I watch Ubuntu's recent steps with trepidation. I love using it for a home
Linux machine (indeed upgrading just to LTS-es), and _I could not care less_
about its "convergence" aspirations. I don't want Ubuntu on my phone or my
tablet, or at least I don't care.

I worry that eventually its mobile plans will bury the desktop Ubuntu, move it
out of focus, so to say. When that happens, I wonder whither I should turn.
Debian?

~~~
dpearson
I used to use Debian, and I'm not sure I'd go back. On one hand, the stability
was wonderful (Debian was pretty much bulletproof for me), but packages were,
for stable, quite old. Hardware compatibility isn't quite as good: hardware
(including a USB Wi-Fi dongle) that Ubuntu autodetects and has no trouble with
became an adventure to get working.

I tracked stable, so maybe testing would be better in terms of package
outdating, but hardware compatibility is Debian's achilles heel right now.

~~~
nonamegiven
Depending on what you do with your machine(s), it might make sense for you to
go with whatever versions come with the vast majority of the packages, but for
the few that matter to you, manage them yourself. For example, I use Oracle's
Virtualbox PPA, and it just updated as a normal software update last night.
That's 4.2.x, compared to Ubuntu's 4.1.x. For things that aren't PPA'd, you'd
need to pay closer attention. It's an option.

------
mattlong
I wonder how much this proposal is driven by Ubuntu's push into the mobile
space versus improving the Ubuntu project at large. Clearly it's possible
rolling releases would aid both.

I guess what I'm really asking is what are the possible negative implications
of the plan for the more "traditional" Ubuntu users? Many of whom are likely
sysadmins trying to maintain consistent package versions across their
infrastructure. Sticking to the LTS versions is the first step. But then you
would be delaying access to newer package versions without the interim
releases.

------
JulianMorrison
One thing I'd add as a suggestion: if they do a rolling release, hot-rebuild
the package so that if you download an "Ubuntu rolling" ISO, you get a 100% up
to the minute copy with all the latest security patches and so forth. This so
that _starting_ a new Ubuntu install is not annoying (which it would be if you
basically had to throw away and redownload the whole OS as updates as soon as
you installed).

~~~
takluyver
There's already a daily ISO of the development release, so I imagine that
would carry on under a rolling release.

------
olenhad
Yes Please! I'm sick of PPA-ing for updated packages.

~~~
homeomorphic
Really? I've always felt that they give me the perfect balance: the distro
itself is non-rolling, so breakages (possibly) happen at known intervals, yet
PPAs let me "go rolling" for a subset of packages where I want the latest and
am prepared to handle breakage at any time.

~~~
gizmo686
I wonder if there is a way to build this process more into the package
management system. Maybe have to sets of repositories, a 'stable' repository
that would behave like current, non-rolling repositories, and a 'rolling'
repository that would get new versions of software once they've been tested.
By default, software would install from the stable repositories, but you can
do something like 'apt-get make_rolling python', and get the rolling release
version of python. Such a system should then be able to handle dependencies
that would need to be made rolling as well.

This clearly means more work for the maintainers, but only because the PPA
method is so clearly a hack that there is no expectation that it must just
work.

~~~
qznc
Apt supports this. However, no distribution officially supports that scheme.

<http://wiki.debian.org/AptPreferences>

[http://serverfault.com/questions/22414/how-can-i-run-
debian-...](http://serverfault.com/questions/22414/how-can-i-run-debian-
stable-but-install-some-packages-from-testing)

[http://blog.drewwithers.com/2011/06/mixing-debian-stable-
and...](http://blog.drewwithers.com/2011/06/mixing-debian-stable-and-
unstable.html)

Debian stable + backports is probably closest. Unfortunatelly, there are few
backports. Partially, because few people use it and partially because upstream
rarely cares for Debian stable.

~~~
sp332
Can't you do this with Synaptic? Include apt lines for multiple versions, then
select "prefer versions from Oneiric". That lets you force a version for
specific packages while not updating the whole system.

------
Nux
This could work, rolling-release + LTS. Archlinux seems to be doing quite well
under the rolling-release auspice, so why not.

Of course, never in my experience has rolling-release ever worked in anything
close to production environments - it's what killed FreeBSD in the data
centre, however, if you're a techie with some time on your hands it could be
cool.

~~~
lorenzfx
totally dead <https://signup.netflix.com/openconnect/software>

~~~
Nux
Not totally dead, it still has some strongholds left, but I'm sure Netflix
doesn't use the rolling-release side of it (ports mainly). :-)

------
themstheones
No one has ever tried this with an OS before.

~~~
schabernakk
What do you mean? Arch and Gentoo are two pretty successful distributions and
both use a rolling release approach.

~~~
wcchandler
Sarcasm doesn't translate very well over the Internet.

------
stormbrew
I'd like to see them balance out dropping the interim releases with doing
slightly more frequent LTE releases. Maybe every 1 or 1.5 years instead of 2.
But obviously there might be manpower issues there. I just think they're
abandoning a middle ground of stability that's still a very valuable space.

------
lorenzfx
I really like the way FreeBSD does it: stable base system but all (ok, most)
3rd party software is still fresh.

------
andyl
This seems like a reasonable proposal to me. I've starting using the LTS
releases exclusively for my desktop and server systems. I'm planning to use
the Ubuntu phone heavily, and would love that device to be on a rolling-
release schedule.

------
mtgx
Canonical should just wait until the 64 bit of 14.04 LTS for ARM is ready
before they put it on mobile. Should greatly simplify their lives when it
comes to upgrading later.

------
smogzer
I can't use Ubuntu, I've tried countless times, the experience sucks. I'm
trying mint, and i can't even access latest libraries, everything is old, no
partition resizing during installation, lack of distro tools and lack of
polish; in mageia everything is fresh and if it not the free support quickly
updates them.

Mandriva had rolling releases with cooker and mageia has also with cauldron.
Sorry for looking like a troll but i never got the hype with this ubuntu
distro, i wish HN supported mageia more since distrowatch even reports mageia
as the number two more popular distro.

~~~
vacri
If you need the bleeding edge of a package, install that package from a pinned
archive (or similar). If you need the bleeding edge of _everything_ , I don't
believe you. If you just want the bleeding edge because 'hey, it feels cool',
then you're not the target demographic for ubuntu - something they stated from
the outset.

