Updated release management straw man for TB consideration

Mark Shuttleworth mark at ubuntu.com
Tue Mar 12 01:33:05 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20130312/9bd14c78/attachment.html>


More information about the technical-board mailing list