Updated release management straw man for TB consideration

[Kees Cook]

Hi,

On Tue, Mar 12, 2013 at 01:33:05AM +0000, Mark Shuttleworth wrote:
> Am writing to ask you to weigh in on an updated release management
> proposal. Details are on Planet Ubuntu, salient portion of the proposal is:

Thanks for this proposal!

> *1. Strengthening the LTS point releases.*
> Our end-user community will be better served by higher-quality LTS
> releases that get additional, contained update during the first two
> years of their existence (i.e. as long as they are the latest LTS).
> Updates to the LTS in each point release might include:
> 
>   * addition of newer kernels as options (not invalidating prior
>     kernels). The original LTS kernel would be supported for the full
>     duration of the LTS, interim kernels would be supported until the
>     subsequent LTS, and the next LTS kernel would be supported on the
>     prior LTS for teh length of that LTS too. The kernel team should
>     provide a more detailed updated straw man proposal to the TB along
>     these lines.

IIUC, this is already in place.

>   * optional newer versions of major, fast-moving and important platform
>     components. For example, during the life of 12.04 LTS we are
>     providing as optional updates newer versions of OpenStack, so it is
>     always possible to deploy 12.04 LTS with the latest OpenStack in a
>     supported configuration, and upgrade to newer versions of OpenStack
>     in existing clouds without upgrading from 12.04 LTS itself.

I would tend to agree with other people here: PPAs seem like the way
forward for these "alternate" stacks of software.

>   * required upgrades to newer versions of platform components, as long
>     as those do not break key APIs. For example, we know that the 13.04
>     Unity is much faster than the 12.04 Unity, and it might be possible
>     and valuable to backport it as an update.

This is new; it would be a modified SRU that explicitly included features.

> *2. Reducing the amount of release management, and duration of support,
> for interim releases*.

So, I would like to find another name for the releases between LTSes. I
do not like the term "interim" as I feel it detracts from the importance
of the 6-month release cadence. I think these releases are critical in
stabilizing Ubuntu. I think the LTS is the "special case" release. It
has been treated as "even more stable" that regular releases, and I
think I'd prefer just using that term instead. "Regular Release" and
"Long Term Support Release".

If we allow ourselves to use the term "interim", I think we'll make the
mistake of thinking these releases are less important.

> Very few end users depend on 18 months support for interim releases. The
> proposal is to reduce the support for interim releases to 7 months,
> thereby providing constant support for those who stay on the latest
> interim release, or any supported LTS releases. Our working assumption
> is that the latest interim release is used by folks who will be
> involved, even if tangentially, in the making of Ubuntu, and LTS
> releases will be used by those who purely consume it.

I have no problem with the idea of reducing the length of support
available for regular releases. (I would also pick 8 months, but wouldn't
be opposed to 7.) This frees up a lot of resources, and encourages
people to upgrade. I've always been a big believer of staying on the
current release of Ubuntu. The LTSes are mostly for people that can't
withstand such frequent changes, but more nimble organizations and
individuals have no problem with a 6-month release cycle. For people
that want bleeding edge, we've still got the in-development release
(obviously more on this later).

Among other things, one of the primary distinguishing characteristics of
Ubuntu is the 6-month release cycle. I would be extremely disappointed to
see that disappear. Adjusting the support time-frame seems like the right
way to shift support resources towards the LTS. (Frankly, I thought we
shouldn't have kept the 18 month support on regular releases when we
moved to having LTS releases.) The point of having a 6-month release
cycle is to USE the 6-month release cycle, which means upgrading every
6 months. :) If you're not doing that, stay on the LTS.

> *3. Designating the tip of development as a Rolling Release.*
> Building on current Daily Quality practices, to make the tip of the
> development release generally useful as a ‘daily driver’ for developers
> who want to track Ubuntu progress without taking significant risk with
> their primary laptop. We would ask the TB to evaluate whether it’s worth
> changing our archive naming and management conventions so that one
> release, say ‘raring’, stays the tip release so that there is no need to
> ‘upgrade’ when releases are actually published. We would encourage PPA
> developers to target the edge release, so that we don’t fragment the
> ‘extras’ collection across interim releases.

I would echo the other concerns about naming here -- this isn't a
"release". It's an always-moving collection. It's a snapshot at the moment
someone runs "dist-upgrade", and not a release. "Rolling Snapshot" I think
would be more in line with what it is. I totally agree with the goal of
making it stable, though.

And here is as good a place as any to voice my concern over this concept.
While I love the idea of a Rolling Snapshot, I am worried its difficulty
is being underestimated. From time to time in the past, there have been
murmurs about moving to a rolling snapshot. I feel these have coincided
with Debian being frozen, and the Ubuntu archive giving the impression
that the incoming package changes were slow and easy to deal with. As
soon as Debian unfroze, these murmurs went away. We cannot control
what will come flooding into the Ubuntu archive from Debian, which is
why stabilization (via regular releases) is so critical to the success
of Ubuntu.

Improving the quality of the Ubuntu archive via automated testing is
a great way to get out ahead of this, and those things are already in
progress. However, I don't think they're nearly to the level of detecting
regressions in DHCP lease delays, UI rendering glitches, streaming codec
performance, etc. There are so many subtle and complex things that are
hard to realistically automate tests for. Now, this should not stop
us from attempting those tests. Every test added is another thing that
we can throw a flag for if it goes wrong, but I think we're not there
yet. I think opening the flood gates from Debian unstable will cause
pain. However, that pain is still less than not opening those flood
gates. Having those changes pour in is what we need to keep the regular
releases coming. I think our cadence with Debian has been very successful.

I think when there are end-to-end usability, performance, and regression
tests in place, and there are people responding to those alerts, then we'll
be in a much better place to have an automated Rolling Snapshot. I want
this. It will be fantastic. I think it's a much longer road.

> As a (possibly) separate matter, in the blog I mention that decoupling
> platform and apps might help us go faster, and encourage app developers
> to make the tough choices about which versions of their apps are
> supported on which releases of the platform. I've left this bit out of
> the core proposal but would think our community would be interested in
> your collective take on that.

What seems to create an App ecosystem is a stable API. If that can be
provided, I think decoupling is almost automatic. (And if those Apps are
closed-source, then you need a stable ABI, which is even harder than a
stable API.) Regardless, I would agree: this is a separate matter.

-Kees

-- 
Kees Cook