Post Release Updates History

Historically, Kubuntu has always provided post-release updates for KDE. Up through Gutsy they were provided through a private repository signed by JonathanRiddell. For Hardy, KDE 3.5.10 was initially provided via backports, and then in hardy-updates. For Intrepid, we provided KDE 4.1.3 and 4.1.4 in intrepid-updates while KDE 4.2.0 was put in intrepid-backports. For Jaunty, KDE 4.2.4 was put in jaunty-backports.

Through these recent evolutions, both Kubuntu and upstream have learned a few things. One of the most critical is to have agreement on the alignment between Qt4 and KDE versions. For Jaunty, Kubuntu released Qt 4.5/KDE 4.2 and upstream was expecting people to release Qt 4.4/KDE 4.2. As a result, there are regressions in the Jaunty KDE packages that upstream does not support and are not resolvable (thus while OK for backports since the issues are minor, they are not suitable for updates).

For Intrepid, Jaunty, and Karmic, updates, both minor and major, have been packaged in PPAs and made available to users. Due, in part at least, to the rapid pace of KDE 4 development these packages are very much in demand from users.

For KDE 3.5.10 and 4.1.3/4, Kubuntu developers were able to work with upstream to ensure that any regressions identified during testing were resolved. By working with upstream, Kubuntu has also benefited from testing and fixes in other distros.

Rationale for providing KDE updates via -proposed/updates

Most of the arguments against doing updates do not apply. KDE micro version releases come close to our release date (KDE 4.3.3 was released less than a week after Karmic), so the idea that users will become accustomed to minor issues and change is more disruptive than the fixes is not applicable. Also, because of the relative maturity of KDE 4 compared to more long lived code bases, the need for continued fixing is greater. There isn't any developer efficiency associated with not providing the packages in -proposed/-updates because developers are packaging them anyway for PPA. Actually putting new microversion updates in updates will reduce maintenance requirements since in the event of a security issue, only the main archive and not the main archive and the PPA will have to be fixed (putting the packages in backports would lose this efficiency and reach fewer users).

Users expect this. Whether it's reasonable or not, users expect us to update to the newest KDE microversion. Upstream does as well. Upstream considers us to be wasting their work on the maintenance updates if we do not use them. Doing the updates will improve Kubuntu's reputation with both users and upstream.

The risk is reasonable. We have done this before and shown we know how to do it.

Lucid will be an LTS release. We want it to be well supported for the full three years and maximizing our use of upstream's bugfix work is part of that. Starting to exercise the process with Karmic will help ensure this goes well. Having packages provided via -updates for LTS will be helpful for ISO respins at point releases.

Kubuntu Updates policy

For any update, Qt and KDE versions must match. Major Qt versions will not be put in -proposed, -updates, or -backports. Qt is used by too many non-KDE packages and part of the platform that needs to be stable. Micro-version updates of Qt would have to be considered on a case by case basis by Kubuntu developers and the Ubuntu SRU team and are unlikely to be accepted.

-updates is promised to be regression free. First, KDE microversion updates will be uploaded to a PPA and tested. Additionally, upstream bug reports and svn commits will be monitored for signs of regression. If regressions are detected, they will be resolved before moving forward. Once PPA testing is satisfactory, the packages will move to -proposed and the testing process will continue with a broader audience. Once testing is complete and the packages are sufficiently aged, they will be copied to -updates. As a matter of practice, KDE upstream limits changes for post-release updates to bug fixes and so KDE micro-version updates will likely be suitable for Ubuntu post-release updates, but in cases where they are not, it may be necessary to decline an update or remove problematic changes. There is a policy for this.

If regressions are detected, they will be worked with upstream and resolved (as long as we have alignment between the Qt/KDE versions that upstream expects, they support this policy). If for some reason an update has a regression that cannot be resolved, if it's minor, the update can be provided via backports (a decision to be made in conjunction with ubuntu-backporters) or if to severe only through a PPA or not at all.

When a new version is uploaded to -proposed, one bug with tasks for all affected packages should be opened and each package should close it in its changelog. This bug will be used to track (via comments) verification of each package. Once all packages are verified, then the bug can be tagged verification-done.

If approved by the Ubuntu Technical Board, this policy would be implemented starting with KDE 4.4.X in Lucid (already tested and ready for -proposed).

Review

This proposal was reviewed by the Kubuntu development community and received positive feedback: https://lists.ubuntu.com/archives/kubuntu-devel/2009-September/003272.html

This policy was approved by the Ubuntu Technical board on November 16, 2010 and should not be edited.

A modification was approved by the Ubuntu Technical board on July 22, 2013. The following packages are added to the MRE:

amarok, bluedevil, libbluedevil, calligra, kdevelop, kdevplatform, kscreen, libkscreen, muon, networkmanagement, phonon, phonon-backend-gstreamer, phonon-backend-vlc, rekonq

Another amendment for the KDE Telepathy packages was approved by the Ubuntu Technical board on September 30, 2013. The following packages are added to the MRE:

ktp-text-ui ktp-send-file ktp-kded-integration-module ktp-filetransfer-handler ktp-desktop-applets ktp-contact-runner ktp-contact-list ktp-common-internals ktp-call-ui ktp-auth-handler ktp-approver ktp-accounts-kcm

This page should still not be edited.