Release Structure Changes

[Scott Kitterman]

As a topic for today's call, I'd like to propose the following.

The latest Ubuntu (the project) level proposal that is on the table is:

https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html

I think we can generally live with this, however (as others have already 
commented on th TB list) I think the 7 month support period is too short.

I would propose the Kubuntu (the project) position on this be something along 
the lines of the following:

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

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

 - 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).  8 months would still be significantly better than 7 if 9 is not 
supportable.

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

In general, the current proposal seems to meet the needs of Kubuntu, but we 
would like to discuss addressing these concerns.  I think the Kubuntu Council 
should vote on a project position on this.

Scott K