Backports PPA policy for 18.04 LTS

user49b user49b at
Wed May 23 13:17:16 UTC 2018

My apologies if I'm being stupid here...
I cannot find anywhere to vote for the options below, so I'm just 
replying here.

Definitely (a) for me...


P.S. Kubuntu 18.04 is awesome.


Our default PPA policy for LTS releases states that [1]

"Monthly KDE software release backports are made available through the
Kubuntu PPA for as long as supported by the native LTS software stack
but no longer than 2 years."

For 16.04 LTS we allowed an upgrade of Qt in the backports PPA [2] from
5.5 to 5.6.x, however this was not altogether a radical decision as the
Qt 5.6 release was a LTS one, and already being built and maintained by
the Ubuntu phone/Qt team in their overlay PPA.

For 18.04 LTS, we are already on Qt 5.9 LTS, with more point releases to
come, hopefully as SRU updates to the main archive.

Now Plasma 5.13 requires Qt => 5.10, so we need to discuss and decide an
acceptable course of action, assuming that we wish to provide this and
future updates update via a PPA to our users.

Realistic options are IMO:

(a) Provide updated Qt once again in our backports PPA, but make it
quite clear that the level of support, both immediate an ongoing, if
users choose to add that and upgrade will be limited by the fact that
they are deliberately choosing to move off an LTS supported stack.

(b) Keep backports PPA building against Qt 5.9.x, and provide Plasma
backports and other software dependant on newer non-LTS Qt in a separate
more 'experimental' PPA.

(c) Something else? Comment welcome.

For simplicity (a) is appealing, and more or less what users seem to be
expecting us to do for them. (b) however has some advantages as it would
perhaps allow users (say organisational ones) to upgrade to new KDE
Applications releases (18.04, 18.08 etc) and others backports, without
moving off LTS supported Qt, assuming future Apps are compatible.

With Plasma 5.13 as few weeks away [3], and bugfix release to that which
we would probably want to wait for before pushing to a not experimental
location, not to mention getting Qt built, we have some thinking time. I
would also note the decision will be tempered by practical and technical
considerations the development team find while doing test builds, and
evaluating the quality and stability of the non LTS Qt.

Thank you. I look forward to comments.

Rik Mills
Kubuntu Council
Kubuntu Developer


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kubuntu-devel mailing list