Release Structure Changes

Philip Muskovac yofel at
Fri Mar 15 13:23:57 UTC 2013

On Friday 15 March 2013 08:57:43 Scott Kitterman wrote:
> 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:
> 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.

The testing side is the only worrysome part, the beta packaging can be done in 
a PPA and bzr just fine. For those people that do care about testing our 
software, promoting the beta PPA for the development series should work.
It would ofc. be less testing compared to putting it in the archive, but for 
beta software it shouldn't be too much of an issue.

> 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

Other than that I agree with Scott.


More information about the kubuntu-devel mailing list