Updated release management straw man for TB consideration

Tue Mar 12 21:49:33 UTC 2013

On 03/11/2013 09:33 PM, Mark Shuttleworth wrote:
> TB,
> 
> 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:

Hi Mark,

Thanks for sending this proposal!

<tldr>
 - Drop support for non-LTS to 8 months.
 - Maybe open the next dev release earlier, allowing for features to
land while the current dev release is frozen.
 - Make some of the SRU criteria a bit more flexible for LTS releases.
 - Make backporting complex stacks easier by allowing for officially
supported external repositories (PPA), integrated in the software-center
and in the other usual bits.
 - Add a flag to the dist-upgrader to monitor and stick to the latest
development release (similar to the LTS-only flag).
</tldr>

>     Updated Ubuntu Release Management proposal
> 
> In order to go even faster as the leading free software platform, meet
> the needs of both our external users and internal communities (Unity,
> Canonical, Kubuntu, Xubuntu and many many others) and prepare for a
> wider role in personal computing, Ubuntu is considering:
> 
> *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.
>   * 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.
>   * 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.

As others said, this looks pretty close to our existing process, with
the exception of some additional packages being backported to -updates
when needed. Assuming that we take great care of testing those extra
packages and don't do any sudden significant UI change or string change,
I think this is all reasonable and makes sense for an LTS.

> *2. Reducing the amount of release management, and duration of support,
> for interim releases*.
> 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'm certainly happy to reduce the number of releases we need to support
in parallel though 7 months sounds a bit short for everyone to upgrade
to the next one, I think I'd be happier with the 8 months suggested by
Colin.

> *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 personally don't like calling this a Rolling Release but I think I'm
pretty much alone there so I'll probably have to live with it ;)
My problem with the term is that I wouldn't call "Release" something we
wouldn't feel confident any of our existing users could use.

Based on some of the other discussions on the matter, it sounds like
we'd aim the "Rolling Release" towards power users who know how to
follow basic instructions to get their system back in working order in
the rare event where we mess up something badly.

So I'm worried that people who see some of the shiny new features that
land in the "Rolling Release" will be tempted to upgrade to it because
of the lack of emphasis on the fact that it's where development still
happens and that they really should stick to LTS unless they know how to
fix their system (or don't care, if they use a VM for example).

I personally would much prefer we still refer to this as the development
release, keep doing things mostly as we do today but caring less about
SRUs to non-LTS.
That wouldn't prevent us from making monthly snapshots, aiming those
very clearly to power users and advising more novice users to use those
in VMs or on spare machines instead of their main production machine.

Quality has improved a lot and the dev release is clearly much more
stable than it used to, though I don't think anyone would like their
parents using it just yet, so I don't think it's a very good idea
attracting users we don't really want.

If the problem is related to the archive being frozen for part of the
cycle, then maybe we should consider opening the next release earlier.
I'm sure it's a bit of a technical challenge but shouldn't be completely
impossible if we get the toolchain ready early enough and Mark can give
us the next name and adjective so we can actually setup the series :)

It should also be fairly straightforward to add an option to the
dist-upgrader to keep a system on the dev release, so whenever the next
dev release is open, it'll ask to upgrade to that one instead of staying
on the stable release.

> 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.
> 
> Thank you!
> Mark

I also want to briefly cover some of the things that were mentioned with
regard to backports. Backports are great and people should definitely
use them more, however they have a few shortcomings which led to the
creation of things like the cloud archive.

The biggest of those issue is that you can only have one version of a
package or set of package in the backport pocket at a time.

This limitation makes backports unfit for things like OpenStack
backports where we want to have 2 or 3 version of the whole OpenStack
stack available for 12.04 users which will then decide to upgrade from
one to the other when they feel like it.

I think this will become more and more of a common problem when we start
focusing more on the LTS and it may be worth looking into covering those
requirements as part of the main Ubuntu infrastructure.

Potential solutions include "official" PPAs, built on production
builders and exposed as a list in the software-center, so that people
can choose to get a whole bunch of backport packages at once and
possibly move to an even more recent backport of that same set of
package later on (but not be forced to).

This is currently done through external archives like the cloud archive
or through source package renames for the enablement stack. I think both
have shown their set of problems and it'd be good to come up with one
standard and official way of dealing with this need.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20130312/1e5331b4/attachment.pgp>