Updated release management straw man for TB consideration

[Scott Kitterman]

Within the Kubuntu subproject (if that's the right word), we've discussed this 
updated proposal  and have through our governance process reached a position 
on it.

In general, the current proposal seems to meet the needs of Kubuntu, but we do 
have a few concerns that we would like to discuss and see if they can be 
addressed.

The overall structure of retaining a regular cadence of normal and LTS 
releases every 6 months is essential to Kubuntu as delivering a release with 
the latest KDE release is a critical part of what makes Kubuntu what it is.  
This revised proposal supports our desired cadence.  

Additional comments on specific points of the proposal are in line below.

On Tuesday, March 12, 2013 01:33:05 AM 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:
> 
> 
>     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.

We expect that most of our user base will run the current release.  We expect 
that users of our LTS release want things to not change.  

We do not support required upgrades to platform components (this is different 
than the hardware enablement updates described in the firs sub-point that are 
done in separate packages and only affect new installs - those we support - it 
should continue to be possible to install the LTS on newer hardware). [As an 
aside and not part of the formal Kubuntu Council response, I'll mention that 
we once did a backport of Qt4 to an earlier release and even though it was 
API/ABI compatible with the previous release, it cause no end of difficulty due 
to internal behavior changes and lack of bug level compatibility - we have 
experience that suggests this is not a good idea.]

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

This assumption does not, in our unscientific opinion, hold true for Kubuntu.  
A large fraction of our user base runs the current release because they want a 
stable release with the current KDE.  

We believe that a one month overlap of support periods (the proposed 7 month 
window) is insufficient.  We would prefer a 9 month period so that users that 
want to wait until the final micro version of a KDE release is complete and 
integrated into the archive can upgrade at this point (as an example, KDE 
4.10.5 is scheduled to release on July 2, 2013 so it would be nice to have 
12.10 [if it had been released under the new paradigm] supported until the end 
of July).  

A three month overlap would allow us to continue to support a slightly more 
conservative portion of our user base.

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

We support the idea of improving the quality and consistency of the 
development series, however, we are concerned that this can be taken too far.  
Our current practice is to wait until at least beta releases of the software 
we package to put them in the archive.  We anticipate continuing this as 
waiting until later reduces the test exposure they get and compresses the 
packaging working into a small period before feature freeze.  We would not 
want the consistency and quality requirements associated with the development 
series to become so stringent that it can no longer be used for development.

Snipped the (possibly) separate matter.

Thanks,

Scott K
For the Kubuntu Council