kubuntu-council team mailing list archive

[Paulo Dias <paulo.miguel.dias@xxxxxxxxx>]

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
| paulo.miguel.dias@xxxxxxxxx

Tempora mutantur, nos et mutamur in illis.

On Tue, May 22, 2018 at 1:47 AM Rick Timmis <ricktimmis68@xxxxxxxxxxxxxx>
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, <rikmills@xxxxxxxxxxx> 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     : kubuntu-council@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kubuntu-council
>> More help   : https://help.launchpad.net/ListHelp

> --
> kubuntu-devel mailing list
> kubuntu-devel@xxxxxxxxxxxxxxxx
> Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel