Hi/2 all. I, for one, agree with Nate Graham. If you are using a backport PPA you don't care much about what LTS has to offer per se, who uses backports (and ppas in general) are much more interested in the latest and greatest. I believe option A is the way to go.
regards | Paulo Dias | [email protected] Tempora mutantur, nos et mutamur in illis. On Tue, May 22, 2018 at 1:47 AM Rick Timmis <[email protected]> wrote: > Hello Rik, Kubuntu > Thank you Rik, for your clear and well set out email. I can see merits in both approaches, and from a technical perspective I would have chosen solution B. > However, my primary concern is with our users, and providing them with the best KDE based distro in a way they have come to expect. With that perspective firmly in mind I believe A is the right way forward. > I say A is the correct approach. > Best Wishes > Rick > On Mon, 21 May 2018 09:12 Rik Mills, <[email protected]> wrote: >> 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 >> [1] https://community.kde.org/Kubuntu/Policies#Long_Term_Support_.28LTS.29 >> [2] https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports >> [3] https://community.kde.org/Schedules/Plasma_5 >> -- >> Mailing list: https://launchpad.net/~kubuntu-council >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kubuntu-council >> More help : https://help.launchpad.net/ListHelp > -- > kubuntu-devel mailing list > [email protected] > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
