Updated release management straw man for TB consideration

[Martin Pitt]

Hello Mark,

Mark Shuttleworth [2013-03-12  1:33 +0000]:
> *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).

I do agree to that statement. During the u-devel@ discussion and vUDS
this came up a lot, and emphasizing LTSes in return for tuning down
the importance/support of non-LTS releases steers development efforts
to where they are most appreciated.

> 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.

I concur to the previous responses; 12.04.2 has shown that this is
actually feasible. The SRU policy should be adjusted to reflect this,
though.

>   * 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.

If the newer version is fully backwards compatible with the old one,
i. e. it doesn't break existing configurations on upgrade, I think
there is room for extending the SRU policy for such cases. But at this
point it becomes really hard to write down a generalized policy. I
would trust our SRU team to decide on a case-by-case basis if a
newer version is appropriate as an SRU, or whether it should rather be
a backport. I'd still prefer -backports to be the default destination,
though.

>   * 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.

It is very important to limit this to cases where all APIs keep
working, not just "key" APIs. Otherwise we'd break lots of third-party
PPAs and software which was written for that particular Ubuntu
release.

I prefer the current compromise of backporting performance and
stability changes, as it happened for precise. Routinely backporting
the whole stack is going to introduce behavioural changes, new/changed
icons in the launcher, or configuration such as disabling workspaces
during upgrade in raring; while that was nasty enough to do during an
upgrade to a new release (still remember the "Golden Rule" from our
beginnings, anyone?), it is a totally unacceptable thing to do for an
LTS. Discussions have shown that a major use case of LTSes is
behavioural stability, so changing the platform goes against this.

That said, if we are looking at some concrete release which changes
more than just what we currently allow by the SRU policy, but does not
break APIs and change the behaviour in a major way, this again could
qualify for an LTS SRU. Again I would trust our SRU team to decide
this on a case by case basis if the general option of doing such
updates is allowed by the policy.

> *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 agree to the other responses, so in short +1 from me. I don't have a
strong opinion about 7 vs. 8 months.

> *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.

This has been our goal since quantal and I don't think anyone
seriously challenged this. However, I'd argue against calling it a
"release", I'd call it the development series or "daily".

As for designating it "rolling" or not, that's mostly quibbling over
names only. Personally I'm fine with naming it like that, given our
efforts on avoiding regressions at all cost and keeping the
development series releasable at all times.

> 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.

I wouldn't call it "raring", as that sounds too much like the actual
stable releases we've been doing. Using a role name like Debian's
"unstable" or "rolling" or "devel" seems more appropriate to me.

As long as we are still going to have actual 6-monthly releases, I
don't think we actually need to reengineer Launchpad for this. We
merely need a "devel" (or whatever name) symlink that keeps pointing
to the name of the current development series to keep upgraders at
the devel series at all times.

> 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.

If "apps" means "packages in Ubuntu which are not part of the default
install", that has been discussed several times already and I don't
think that this works (agreeing to what Colin said).

If "apps" means the "new style" apps that we are introducing with the
new "Ubuntu SDK", i. e. which only expose a well-defined API, them I'm
all for this. I'd even say that we won't be able to attract a lot of
app developers if we can't keep this API reasonably stable.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20130313/f39482cd/attachment.pgp>