Avoiding fragmentation with a rolling release

Thu Feb 28 20:14:56 UTC 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The six-monthly Ubuntu release cycle is exciting for Ubuntu fans, KDE
fans, and (lesserly) Gnome fans ... and awful for pretty much everyone
else.

It's awful for first-time users trying to choose a version, for ISVs,
for OEMs and ODMs, for people who write and run training programs, for
Ubuntu-related book authors, publishers, and sellers, for people
providing tech support, and for Ubuntu developers themselves trying to
release features in a finished state. Little wonder that some of those
groups ignore non-LTS releases altogether.

So, I'm all in favor of having two-yearly releases. But for the same
reasons as six-monthly releases are bad, monthly snapshots and/or a
rolling release would be much worse -- unless we are careful to
communicate that they are for contributors only, not for end users or
ISVs.

Rick Spencer wrote on 28/02/13 15:31:
> ...
> 
> = Role of the LTS Releases =
> 
> Many users prefer their OS does not change very often. We have a 
> great system in place for these users. Every 2 years Ubuntu
> release an LTS and users can ride that LTS for the whole support
> period. Since the LTS comes out every 2 years, they can set a 2
> year cadence of updates if they want to stay "up to date" with LTS 
> releases. I think this 2 year cadence works out very well for
> these users. So, this proposal maintains those LTS releases as
> anchors for those users.

LTS-to-LTS upgrades are tested, and documented, much less than they
would be if they were the only type of end-user upgrade. For that
reason alone, having LTS-only releases would be a good thing.

> ...
> 
> * Many community members recommend only LTS releases to new users 
> because of its longevity and stability, but the interim releases 
> cause confusion about what is the “right” version for someone to 
> install.

For evidence of that, you need only look at
<http://www.ubuntu.com/download/desktop>. "The latest features", or
"long-term support"? That's a question people can't reasonably be
expected to know the answer to. It's a choice they should not have to
make.

> * As Scott James Remnant pointed out some time ago, the six month 
> cadence causes features to be either rushed, or to have to wait
> for six months to be released (along with other problems). 
> (http://netsplit.com/2011/09/08/new-ubuntu-release-process/)

LTS-only releases would not solve that problem, but they would reduce
the problem by about 75 percent (three releases out of four).

Less time spent on the release process itself would also allow
more time for actual development. But on the other hand, the urge to get
features and other major changes into an LTS would be even more
frantic and rule-bending than it is for every release now. There would
be no post-LTS interim release as a consolation prize, and two years
is a long wait.

> ...
> 
> More clearly, I think we should:
> 
> * Stop making interim releases.
> 
> * Keep doing daily quality and keep improving our daily quality.
> 
> * Take a monthly snapshot of the development release, which we 
> support only until the next snapshot

For software, the word "support" is incurably vague and best avoided.
What do you mean? Security updates? Backports? Tech support from
Canonical? A section on help.ubuntu.com? A listing on
friendly.ubuntu.com? Repackaging of commercial applications in Ubuntu
Software Center?

I don't understand why you are proposing monthly snapshots at all. Can
you elaborate?

> That means users could choose:
> 
> * The LTS release
> 
> * The rolling release updated daily or as frequently as desired
> 
> * The rolling release updated at least monthly

For example, what is the difference between "daily or as frequently as
desired" and "at least monthly"? Why have both?

> = Benefits of Moving to a Rolling Release =
> 
> A rolling release instead of interim releases will benefit users, 
> community members, and developers.
> 
> == For Users ==
> 
> Users who prefer the LTS releases will be unaffected by this 
> change, at least directly. For users who prefer more up to date 
> software, the rolling release will truly provide the latest and 
> greatest software that they are looking for, but without the 6 
> month wait for a new release. Developers won’t be under pressure
> to rush a feature in before the release deadline, so users will be 
> receiving more complete software when they do get updates.

That would leave, unmeliorated, the biggest problem for users: that,
as you said, "the interim releases cause confusion about what is the
'right' version for someone to install".

A download page that offers a choice between the LTS and a rolling
release would be exactly as horrid as one that offers the choice
between the LTS and a six-monthly release.

Instead, I suggest that the rolling release be clearly targeted only
at Ubuntu contributors. At developers, testers, translators, but not
end users. Not shown on the download page, not "supported" in any
sense, and not listed anywhere except cdimage.ubuntu.com or its successor.

> == For Community ==
> 
> The community will benefit from the simplified model. They will be 
> able to recommend either the LTS or the rolling release, and the 
> users of each will be clear. People who need to provide support may
> find their lives dramatically simplified, because on any one day,
> there will essentially be 2 releases with clearly differentiated
> user bases instead of their user base being distributed across a
> minimum of 3 supported releases. For example, on any one day, an
> ISV typically would only have to worry about the LTS releases and
> the current rolling release, instead of 11.10, 12.04, 12.10 and the
> current development releases, Raring.

Another reason end users should not be offered rolling releases is
that they would be a bad platform for ISVs.

During the Ubuntu 12.10 development cycle, the messaging menu API
changed for architectural reasons. Every application using it broke,
but that wasn't so bad -- because end users weren't using it, OS
developers expect things to break, and most of those applications were
fixed before the 12.10 release.

But if that change had happened during a rolling release used by end
users, either end users would have experienced the breakage, or we
would have had to pay the cost of reimplementing the old API alongside
the new one. That would be a cost our competitors do not pay -- or pay
only because they benefit from vastly more and older third-party
applications than we do.

That is not an isolated case. There have been similar API changes
for application indicator menus, for Unity lenses and scopes, and
probably for subsystems I've never even heard of. With an end-user
rolling release, if you installed OS updates overnight, an application
you had paid money for could stop working while you slept.

The attractiveness of a platform to ISVs depends, among other things,
on the homogeneity of versions amongst the user base. Right now, of
PCs running Ubuntu 12.04 or later,

54.6 % are running 12.04 LTS,
44.9 % are running 12.10, and
0.5 % are running R.

As far as ISVs are concerned, that's pretty close to the worst
possible fragmentation of just those two releases. But at least 12.10
is a stable target!

Now imagine that 12.10 didn't exist. Our success as a platform would
depend on how much of that 44.9 % were instead using 12.04, a stable
target, rather than R.

That's why we need to be as clear as possible that the rolling release
is for contributors only.

> ...
> 
> == Because we Can ==
> 
> Daily Quality means that developers can ensure their components are
> stable and useful before they upload, and our processes protect us
> from most mistakes these days. The result is that 13.04 has been as
> robust a release over the last many weeks as 12.10 was when we 
> delivered. We have achieved rolling release quality in our 
> development practices, so we can capitalize on this capability 
> now.

Comparing with 12.10 is an easy target: 12.10, even after hundreds of
SRUs, is roughly 20 to 40 percent crashier than 12.04.

Even then, your statement is true only if you change "the last many
weeks" to "yesterday". It was only yesterday that R's error rate came
close to 12.10's -- for both, about 0.07 errors per reporting machine
per calendar day. For most of the past month, R has been much
crashier: between 0.10 and 0.15. <https://errors.ubuntu.com/>

So if there is a plan to make daily Ubuntu versions as stable as
interim releases, it has yet to be demonstrated.

Cheers
- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEvusAACgkQ6PUxNfU6ecq0FwCgkPR1QKbgNCl41S+hHAr2PlzW
NlcAmwTJFDLKilvPy+85hr8xTldDjjYb
=3yCV
-----END PGP SIGNATURE-----