Updated release management straw man for TB consideration

[Rick Spencer]

Thanks to Mark for brining this forward. I think this proposal does an
excellent job of capturing the gestalt of the conversations about our
release cadence and support models. It also seems reasonably iterative
and implementable.

Point #2 sounds *very* similar to what came out of discussions in UDS.
Such a support scheme was favoured by many members of the community I
talked to last week during UDS, including the Xubuntu community
members I talked to in their session. In fact, one of them was to be
taking the lead to describe a similar proposal to yours here:
https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease
though clearly he has not gotten far in making the actual definition.
Would it make sense to begin refining the proposal there?

I chatted with him last night on irc after you posted yor proposal. He
has some refinements that he would make to your proposal, but in
general was satisfied, because, as I said, this was the sort of
solution that the Xubuntu community strongly supported.

In terms of making the development release the "rolling release"
(Point #3), I think the point is actually pretty elegant. For the
notion that you can use the very bleeding edge or be slightly buffered
from it, we do have a tool in our toolbox that we can/should deploy
for this, Phased Updates:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-phased-updates
. xnox (Dmitrijs Ledkovs on the foundations team) proposed that we
turn this on for the development release for non developers. In this
way, whoopsie-daisey would provide an automated buffer zone for people
who wanted to ride tip but wanted a degree of protection as well. If
developers were experiencing bugs from a package, daisey would know
and would stop the update from going to the next set of users.

Cheers, Rick

On Mon, Mar 11, 2013 at 6:33 PM, Mark Shuttleworth <mark at ubuntu.com> 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:
>
> 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.
>
> 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.
>
> 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.
>
> 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