Backports PPA policy for 18.04 LTS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Backports PPA policy for 18.04 LTS

Rik Mills-2
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


--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Kubuntu-council] Backports PPA policy for 18.04 LTS

Aaron Honeycutt-2
Rik,

Thank you for making this email and the links. Would a Non-LTS PPA work for those who want to be on the latest and an LTS PPA for organisations?

On Mon, May 21, 2018 at 2:12 AM Rik Mills <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~kubuntu-council
More help   : https://help.launchpad.net/ListHelp

--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Kubuntu-council] Backports PPA policy for 18.04 LTS

Valorie Zimmerman-3
In reply to this post by Rik Mills-2
On Mon, May 21, 2018 at 1:12 AM, Rik Mills <[hidden email]> 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.

I think that this is not a good idea for Bionic.

> (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.

How about something like Plasma-Backports PPA? Make it clear, as you
say, that updating Qt and Plasma this way will mean hopping off the
LTS train. Having a regular Backports which allows LTS users to
upgrade applications and Plasma LTS is good.

> (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

Thanks for asking!

Valorie

--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Kubuntu-council] Backports PPA policy for 18.04 LTS

Nate Graham-2
Personally I'd prefer to upgrade Qt in the backports PPA. People who use
that PPA already know they're hopping off the LTS train and want the
latest and greatest from KDE. I think the overlap between that group of
people and the people who are okay with upgrading Qt is pretty much 100%.

Nate


On 05/21/2018 07:52 PM, Valorie Zimmerman wrote:

> On Mon, May 21, 2018 at 1:12 AM, Rik Mills <[hidden email]> 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.
>
> I think that this is not a good idea for Bionic.
>
>> (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.
>
> How about something like Plasma-Backports PPA? Make it clear, as you
> say, that updating Qt and Plasma this way will mean hopping off the
> LTS train. Having a regular Backports which allows LTS users to
> upgrade applications and Plasma LTS is good.
>
>> (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
>
> Thanks for asking!
>
> Valorie
>


--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Kubuntu-council] Backports PPA policy for 18.04 LTS

Rick Timmis-3
In reply to this post by Rik Mills-2
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, <[hidden email]> 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     : [hidden email]
Unsubscribe : https://launchpad.net/~kubuntu-council
More help   : https://help.launchpad.net/ListHelp

--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Kubuntu-council] Backports PPA policy for 18.04 LTS

Paulo Dias
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
| [hidden email]

Tempora mutantur, nos et mutamur in illis.

On Tue, May 22, 2018 at 1:47 AM Rick Timmis <[hidden email]>
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, <[hidden email]> 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     : [hidden email]
>> Unsubscribe : https://launchpad.net/~kubuntu-council
>> More help   : https://help.launchpad.net/ListHelp

> --
> kubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Backports PPA policy for 18.04 LTS

user49b
In reply to this post by Rik Mills-2
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...

Regards
Chris

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

[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




--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel