Release Structure Changes

Ho Wan Chan smartboyhw at
Fri Mar 15 13:02:11 UTC 2013

Not a Kubuntu Council member (just a Kubuntu member) but I am +1 on this.

Howard Chan (smartboyhw)

2013/3/15 Scott Kitterman <ubuntu at>

> 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,
> 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
> --
> kubuntu-devel mailing list
> kubuntu-devel at
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kubuntu-devel mailing list