Ubuntu, Rolling Releases and Support

24 Nov

There’s been a lot of chatter about Canonical moving Ubuntu from the current 6-month release cycle to a rolling-release style of distribution. First, I’ll just explain what the two distribution methods are, their strengths and weaknesses, and finally how Canonical fits into the picture.

Fixed Release Cycles

Fixed release cycles date waay back to the 1980s some time. Maybe. I’m not sure. All I know is, this distribution method is really really old. It’s tried and true. I’m going to demonstrate what goes on in this release cycle.

Start ——————————–> Code
This line represents time. As time passes, code gets added, shifted and taken away from the central project (in this case Ubuntu): it could come from new application versions (as with Firefox) or from Canonical (as with Ubuntu One or the Me Menu). All that’s important right now is to realise that code is constantly being changed in the project.

Start ———————————> Code
                              ` Stable release marked!

Now, the line has a branch coming out of it. Canonical have said, "These are the applications that we want to include in [10.10]". Now, the amount of code allowed into the project is being limited to fixing stuff.

Start ———————————> Code
                              `————–> Stable Release Released!

So Canonical have been working on that branch since it was marked, fixing stuff that people reported as broken. In the meantime, people are also adding whatever code they like to the project (whether directly to Ubuntu or indirectly through a 3rd part project like Firefox). The stable release is out and people are downloading it. Yay! Now, no new versions of applications make their way into the stable release and the amount of code going in is severly restricted to fixing important bugs.

Start ————————————————————–> Code
                              `————–> [10.10] — — — — — –>

So in actuality, when Canonical works on Ubuntu, they’re actually working on two (well, three, as explained later) projects – the current stable release of Ubuntu (dashed here), fixing things that are broken or vulnerable, and the next release of Ubuntu, which gets new features, new artwork and more sexy. The top line will eventually branch again into the next release [11.04] and when it does, support will drop for the current version. The exception is in LTS releases, that also get their own branch – this would go below the dashed line and carry on until every 4th release, when a new one comes out. So, Canonical actually keeps 3 code paths for Ubuntu: one is for lots of features; one is for bug-fixes for the next release; and one is a 2-year-long support code path.

Rolling Release

Rolling Release distributions are much more hectic to keep track of and aren’t as simple as the Fixed Release Cycle above. Rolling Release distributions let you install a, "base" system, then receive updates for applications progressively. Some distributions (such as Gentoo) let you install the very latest and greatest releases of applications when the applications get updated, though others can potentially hold back appplications until they’ve been proved to work with the system to maintain stability. Unlike the fixed release cycle above, applications will receive updates that include new features and new application versions. They receive much less QA testing from the distributors, but if the independent projects do their own extensive QA testing this may not be an issue.

Canonical: Rolling Release Vs. Tried and True

The question of whether Canonical should move to Rolling Releases is a question of cost-benefit analysis. I’m a tinkerer and a geek, most of my family are and I’m sure, if you’re reading this, you probably are too. There are also people that can quickly figure out what’s changed, how it’s changed and how they adapt to the change when new versions of applications come out (these people tend to be our younger generations, as they have grown up around and lived with computers all their lives). For these people, Rolling Release is very advantageous: we get newer software with newer features faster. When a new release of Firefox comes out, I want it – there and then, not with the next release of Ubuntu. When a new version of Rhythmbox, or Empathy, or Evolution comes out, or a new release of Amarok, KDE SC or KDEPIM comes out, I want to be able to install and use it without worrying about PPAs and without worrying about stability (except, maybe, in KDE SC – depending on who you ask). This is how third-party applications on Windows work, badly designed as updating software is on Windows, and rolling release seems to work well for consumers there.

However, in corporations especially, this isn’t OK for various reasons. First, keeping the software at a specific version for a long period of time (2 years for LTSes) means that, when there’s a problem, the guys in I.T know what to do to solve it. If application versions keep bumping every few weeks, with new features, changing layouts and the like, I.T could bump against a problem they’ve never experienced before, or experience an old problem only to find that the method of solving it has changed (menus, configuration options have changed etc.). This is a massive inconvenience. Then consider that many corporations may have specialised or in-house-developed software, built against only one version of a set of libraries underneath: if these keep updating and changing, or even if something as simple as the default theme keeps changing, it could break something in that application. Since we know that application is made in-house, or a software house has been sponsored to develop it specifically for them, we can assume that it’s pretty damn important and that having it break every few weeks could mean plenty of hours lost constantly trying to fix it. Not cool.

These aren’t the worst of it, though. Gather ’round this campfire, ’cause I’m going to tell you a horror story my father told me: he’s every bit a geek that I am and loves his technology, so he knows how to look after himself in the digital world. But at his workplace, in a hospitle, he goes towards the locker room every morning and evening which is locked with a key-code – except this night, when he approached that locker room door, he found on the wall beside it – not blood, but something much, much worse… the code to the locker room, written in permanent black ink. Terrified, he fled at the site, retreating to his familiar and comfortable computer desk, with the shared computer – only to find that there, too, was written someone’s user-name and password, on a sticky note on the side of the computer screen.

Horrific, I know – but the sad reality is that these people are a majority. These are the kind of people I.T has to cope with, and they seem to panic as soon as anybody suggests they move out of the groves they’ve worn in their minds. So, you can imagine, having the software they use change every week or so is a nightmarish hellride – no, not for the stupid plebs, but for the poor, poor guys in I.T. Think of the I.T department: offer a fixed release cycle.

All that being said, I don’t see any reason why Canonical can’t use both methods – simply take a, "snapshot" of the package versions every two years and slap on an, "LTS" sticker, then have everybody else use the rolling-release cycle. I certainly think it would be better for Ubuntu’s current user-base. I’m holding out hope, anyway. Well, there go all my hopes and dreams. :/


One Response to “Ubuntu, Rolling Releases and Support”

  1. manny November 25, 2010 at 02:12 #

    nice explanation.

    I wish my dad was more like yours, he’s pretty terrified of the computer, but at least he knows how to “browse the net” now.

    too bad they didn’t follow your suggestion, it was pretty good. But lets see what happens..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: