reflecting on first UDS session on "rolling releases"

[Robert Collins]

On 6 March 2013 12:49, Allison Randal <allison at ubuntu.com> wrote:
> There were a few things that concerned me in today's session on cadence
> of rolling releases:
>
> http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/
>
> But, the biggest was at the very end when System76 said that two years
> is too long between releases for their customers, but that they were
> willing to at least *try* the new rolling releases. The reply was that
> the rolling releases weren't expected to be stable enough to deliver to
> customers. This surprised me, since "stability" is exactly the purpose
> of rolling releases.

It surprises me too. Google are doing regular updates - daily -
http://googlechromereleases.blogspot.com/ - so it is clearly doable.
Now it is true that Chromebooks have a vastly smaller surface area
than Ubuntu main, but surface area isn't the key with rolling release
stability.

IMNSHO The key with rolling release stability is making each change
small enough to validate properly. Thousand line updates are hard to
validate properly. Ten's of thousands of lines even less so. And we're
very dependent on upstream making sensible changes too.

With bzr we ran for some years with monthly releases and eventually -
largely to fit in with Ubuntu schedules - switched to 6 monthly. I
thought at the time that was a mistake, and I still do - the result of
a slower release schedule was more pressure to break compatibility in
each release (because the benefits of backwards compat were relatively
lower, as noone was expected to be depending on behaviour in interim
releases).

Launchpad got itself out of the doldrums by moving away from monthly
releases - with batched up QA and relatively large risky migrations -
to daily (multiple times a day now) releases, with every change
[intended to be] backwards compatible and safe to do incrementally. It
is slightly higher overhead on each change, but more than offset by
the ability to stop mid-arc and head in a different direction safely,
and rapid feedback about the suitability of changes (because you can
learn as you go rather than once you are finished).

tl;dr - you don't need a massive engineering team to do high quality
low breakage continual deployment. What you need is some supporting
automation and care and attention to detail on each change you *do*
make.

> If the "rolling releases" really aren't intended for end-users, then we
> should just drop the fiction, say the change is from a 6-month cadence
> to a 2-year cadence, and be done with it.

Agreed.

> Yes, it has all the problems we've come to know-and-hate with stale
> applications. So, either allow SRU exceptions for more applications like
> we do for Firefox, or start really supporting Backports for the LTS.
>
> It's a waste of everyone's time and effort to rework the whole project
> around talk of "rolling releases" when it's really just the same old
> development release on a slower schedule. (Remember how we used to call
> monthly images alphas and betas? That was ages ago, like 4 whole months.)

I think Adam's suggestion of treating all our uploads as things to do
phased exposure too, and using automatic signs - crashes and
exceptions from a small part of the userbase - to trigger a halt to
propogation, or even an automated reversal - a very good one.

A rolling release that isn't actually *always releasable* isn't a
rolling release.

Just saying.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services