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 -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
