[opensuse-kde] Plasma 5.8 and openSUSE 42.2
Hello, As you know, a few weeks ago KDE announced Plasma 5.8 would be a LTS release. I think the decision to create a LTS release was at least partly caused by our (openSUSE) needs, so I think it's nice of them to decide to do that for us and I think it would benefit both KDE and openSUSE if we included Plasma 5.8 in openSUSE Leap 42.2 . 18 months of upstream support? I'm sure nobody would say no to that. The problem comes when one looks at the schedules for Plasma and openSUSE Leap releases: https://community.kde.org/Schedules/Plasma_5 https://en.opensuse.org/openSUSE:Roadmap The main part of the current schedules is: 2016-08-25: openSUSE 42.2 Beta 1 2016-09-15: KDE 5.8 Repo Freeze 2016-09-21: openSUSE 42.2 Beta 2 - Package freeze 2016-09-29: KDE 5.7.95 LTS (5.8.0 Beta) 2016-10-06: openSUSE 42.2 RC1 2016-10-13: KDE 5.8.0 LTS Release 2016-10-18: openSUSE 42.2 RC2 first week of November 2016: openSUSE 42.2 Release As you see, there's quite bad timing in there. I've talked with some plasma developers and Ludwig separately trying to move both schedules around in a way that could make it possible to get 5.8.0 in openSUSE 42.2. I have a proposal that I think (and hope) that will satisfy everyone so I think it's time to move this forward to all involved parties. In that sense, I wrote a very similar mail to the plasma developers and will send it at the same time than this one. I hope you like the proposal and note that I've tried to keep in mind the needs of each project (QtCon/Akademy dates and the desire to have a stable Plasma release on one side, SUSECon/SLE12SP2/other dates and the desire to have a stable openSUSE release on the other). This mean bringing forward some kde release dates and postponing some openSUSE pre-releases to make everything fit tightly: 2016-09-01: openSUSE 42.2 Beta 1 (this would include the last Plasma release available at that time, 5.7.4 or 5.7.5) 2016-09-08: Plasma 5.8 Repo Freeze (last day of Akademy, maybe that could be moved to freeze the repo just before QtCon?) 2016-09-15: Plasma 5.7.95 LTS (aka 5.8.0 Beta) 2016-09-21: openSUSE 42.2 Beta 2 - Package freeze (with 5.7.95) 2016-09-29: Plasma 5.8.0 LTS Release 2016-10-06: openSUSE 42.2 RC1 (with Plasma 5.8.0) 2016-10-11: Plasma 5.8.1 LTS 2016-10-18: openSUSE 42.2 RC2 (most probably including Plasma 5.8.1 if bugs found and depending on the size of changes) 2016-10-18: Plasma 5.8.2 LTS 2016-11-01: Plasma 5.8.3 LTS First week of November 2016: openSUSE 42.2 Release Following that schedule means that openSUSE 42.2 would be released including 5.8.1. This would mean too that we (can I include myself as a kde packager too? :) ) would have less time to package KDE releases for 42.2 and less time to test them too since some openSUSE betas would be postponed but RC1 and RC2 would stay at the same dates. Ludwig also mentioned he's willing to shift the Leap schedule a bit more if needed, but for now, the proposal is what's stated above. So, my question is, would you agree with that? Anybody sees any problem if both projects agree to those changes to their respective schedules? Please, keep in mind that both projects have needs and requirements, but it would be great to find one solution that benefits both of us and for that, both projects have to give in a little. Thanks, -- Antonio Larrosa alarrosa@suse.de larrosa@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Hi Antonio, On Tuesday, 26 July 2016 15:56:16 CEST Antonio Larrosa wrote:
This mean bringing forward some kde release dates and postponing some openSUSE pre-releases to make everything fit tightly:
Following that schedule means that openSUSE 42.2 would be released including 5.8.1.
In my opinion one important point is being overlooked. We have a LTS version for Plasma, but as far as I know we do not have LTS versions for Frameworks nor Applications. So we should first discuss and align the maintenance strategy before even discussing the version of these components. Would it be possible to update the Frameworks, Plasma and Application components in Leap 42.2 through the normal maintenance channels (like we have been doing a couple of times for Leap 42.1), or is the maintenance for 42.2 now restricted to pure bugfixes and versions of packages should be kept at the same level as the release ?? Without the above it would be hard to determine how to proceed. If we can update the KDE components to newer versions, then we do not have to push and squeeze ourselves to get a particular version in. If the maintenance channel would be closed for functonality and/or version upgrades, then we need to decide on which version for Frameworks, Plasma and Applications we want to have in Leap 42.2 given the release schedule. This would also mean that a lot of work might come towards a very small team as that fixes in newer releases need to be backported against the older version, which sometimes might not even be possible. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data martedì 26 luglio 2016 16:40:18 CEST, Raymond Wooninck ha scritto: Hello,
for Plasma, but as far as I know we do not have LTS versions for Frameworks nor Applications.
Frameworks, are, IMO, the least of our problems because of the long-term commitment of API and ABI stability. Therefore there would be no problem (in theory) to keep updating Frameworks on top of 5.8. Everything should keep working as it should. This is not necessarily true for Applications, however. This is because until the upstream dependency freeze is in effect (before the beta), requirements and dependencies can be changed. Currently this is a real problem mainly on fast-moving targets like PIM, most of the other applications are more lenient towards "new versions of everything" and therefore are less prone to breaking. My personal opinion would be to evaluate whether updating to the new(er) Applications releases, but talking with upstream about this situation to lessen the pain. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
Raymond Wooninck schrieb:
On Tuesday, 26 July 2016 15:56:16 CEST Antonio Larrosa wrote:
This mean bringing forward some kde release dates and postponing some openSUSE pre-releases to make everything fit tightly:
Following that schedule means that openSUSE 42.2 would be released including 5.8.1.
In my opinion one important point is being overlooked. We have a LTS version for Plasma, but as far as I know we do not have LTS versions for Frameworks nor Applications.
So we should first discuss and align the maintenance strategy before even discussing the version of these components. Would it be possible to update the Frameworks, Plasma and Application components in Leap 42.2 through the normal maintenance channels (like we have been doing a couple of times for Leap 42.1), or is the maintenance for 42.2 now restricted to pure bugfixes and versions of packages should be kept at the same level as the release ??
Good point. Leap's message is to prefer working components over the latest and greatest and I'd wish that it's default desktop would somehow reflect that spirit too. As such switching to a Plasma LTS release fits the story well. However, planning to have a kind of buggy default desktop and to release an online update for it right when we release 42.2 doesn't. Therefore I'd like to have e.g 5.8.1 on GM if that has the most obvious bugs fixed already. I'd probably rather move some milestone than shipping .0. The update channel technically does not forbid version updates. Still we have to keep the use case of Leap in mind. Therefore I'd rather not repeat such KDE version updates as we had in 42.1. Esp intrusive ones that add new packages, obsolete others and cause build failures etc. So if Plasma, Framework or Applications are developed and released independently, maybe upstream needs to sit together and come up with Framework and Applications releases that fit the Plasma LTS one. All three components together form KDE and the impression people get from it after all. Since we promote KDE as default desktop the impression does rub off on Leap. So it better be a good one. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data mercoledì 27 luglio 2016 16:46:11 CEST, Ludwig Nussel ha scritto:
come up with Framework and Applications releases that fit the Plasma LTS one. All three components together form KDE and the impression
There is no "KDE" anymore, KDE is the community which makes 3 different pieces of software. With regards to Frameworks, as I said, Plasma 5.8 will have hard-dependencies on the minimum version needed to run it. Applications are a different story, because they're not tied to the DE anymore: one of the many reasons "KDE" indicates the community, and not the software. As Raymond hinted, however, there's not enough manpower to backport stuff regularly. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Onsdag den 27. juli 2016 17:00:11 skrev Luca Beltrame:
In data mercoledì 27 luglio 2016 16:46:11 CEST, Ludwig Nussel ha scritto:
come up with Framework and Applications releases that fit the Plasma LTS one. All three components together form KDE and the impression
There is no "KDE" anymore, KDE is the community which makes 3 different pieces of software.
With regards to Frameworks, as I said, Plasma 5.8 will have hard-dependencies on the minimum version needed to run it. Applications are a different story, because they're not tied to the DE anymore: one of the many reasons "KDE" indicates the community, and not the software.
As Raymond hinted, however, there's not enough manpower to backport stuff regularly.
Wouldn't including Plasma 5.8 to begin with reduce the workload? Compared to shipping 5.7 and then do a semi-major upgrade later? And also doesn't Plasma 5.8 being LTS remove the need for the openSUSE team to backport (Plasma) patches? I thought that was more or less the whole idea of the LTS. Of course I don't really know how much work goes into shipping the Plasma bugfix releases. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Wed, Jul 27, 2016 at 7:55 PM, Martin Schlander <martin.schlander@gmail.com> wrote:
Onsdag den 27. juli 2016 17:00:11 skrev Luca Beltrame: Wouldn't including Plasma 5.8 to begin with reduce the workload? Compared to shipping 5.7 and then do a semi-major upgrade later?
We are all on the same page with regards to Plasma. But Plasma is just the desktop and nothing else. Applications like kate, kmail, kontact, okular, marble, etc are not included in Plasma, but are released independently with KDE Application releases. These are the components that Luca was indicating.
And also doesn't Plasma 5.8 being LTS remove the need for the openSUSE team to backport (Plasma) patches? I thought that was more or less the whole idea of the LTS. Of course I don't really know how much work goes into shipping the Plasma bugfix releases.
As stated before, Plasma LTS release will have a dependency on a particular Frameworks release, so this we could see as one set. My expectation is that we would have regular updates for Plasma 5.8 in the same sense as that we had for kdebase-workspace. However Frameworks itself does not have an LTS release, so bugfixes will only be in a newer version. Of course the indication is that Frameworks will remain API/ABI stable and backwards compatible, but we have never had that situation. So if we want to keep Frameworks on the starting release, we would need to start backporting fixes. For KDE Applications this situation is even worse as that here in most cases a newer Frameworks and newer Plasma version is required with every update. So if we select the KDE Applications 16.08 as the main version (which would be available version at that time), then we would need to accept the given functionality provided (including the KF5 porting part). At least based on what Ludwig is indicating. As of this moment this could mean that we have to accept that maybe a number of bugs can never be fixed as that the fixes can not be backported (either due to functionality changes or due to available manpower). -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data giovedì 28 luglio 2016 11:08:59 CEST, Raymond Wooninck ha scritto:
For KDE Applications this situation is even worse as that here in most cases a newer Frameworks and newer Plasma version is required with
Some more points to add to the dicussion: Usually Framework dependencies are per-project (which complicates things), what we have seen historically is that Plasma *may* require a newer Applications version for some functionality (one only case known so far: events shown in the calendar). -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Torsdag den 28. juli 2016 11:42:39 skrev Luca Beltrame:
In data giovedì 28 luglio 2016 11:08:59 CEST, Raymond Wooninck ha scritto:
For KDE Applications this situation is even worse as that here in most cases a newer Frameworks and newer Plasma version is required with
Some more points to add to the dicussion: Usually Framework dependencies are per-project (which complicates things), what we have seen historically is that Plasma *may* require a newer Applications version for some functionality (one only case known so far: events shown in the calendar).
So how about a model where: Leap is released with Plasma 5.8. And only gets upstream Plasma 5.8 bugfix releases via the official update channel. Frameworks can stay at the initial version. Or it can be upgraded to a newer version if there are very critical bugs or security issues that are fixed - or it can be upgraded at the discretion of the KDE team. Personally I'm willing to gamble on the ABI/API stability of Frameworks. But no point in upgrading just for the sake of upgrading. I assume Ludwig is OK with this too? Applications can stay at 16.08.x. Or they can be upgraded if Frameworks is upgraded first. But personally I'd prefer applications not to have feature upgrades during the Leap release cycle, as I am a big kdepim user who don't like surprises ;-) As I see it, Leap users (i.e. stability and predictability afficionados) and the KDE team have a common interest in not messing around with Leap more than necessary. But I could be missing something. We have Tumbleweed and OBS repos for other use cases. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Martin Schlander schrieb:
Torsdag den 28. juli 2016 11:42:39 skrev Luca Beltrame:
In data giovedì 28 luglio 2016 11:08:59 CEST, Raymond Wooninck ha scritto:
For KDE Applications this situation is even worse as that here in most cases a newer Frameworks and newer Plasma version is required with
Some more points to add to the dicussion: Usually Framework dependencies are per-project (which complicates things), what we have seen historically is that Plasma *may* require a newer Applications version for some functionality (one only case known so far: events shown in the calendar).
So how about a model where:
Leap is released with Plasma 5.8. And only gets upstream Plasma 5.8 bugfix releases via the official update channel.
Frameworks can stay at the initial version. Or it can be upgraded to a newer version if there are very critical bugs or security issues that are fixed - or it can be upgraded at the discretion of the KDE team. Personally I'm willing to gamble on the ABI/API stability of Frameworks. But no point in upgrading just for the sake of upgrading. I assume Ludwig is OK with this too?
Applications can stay at 16.08.x. Or they can be upgraded if Frameworks is upgraded first. But personally I'd prefer applications not to have feature upgrades during the Leap release cycle, as I am a big kdepim user who don't like surprises ;-)
As I see it, Leap users (i.e. stability and predictability afficionados) and the KDE team have a common interest in not messing around with Leap more than necessary. But I could be missing something. We have Tumbleweed and OBS repos for other use cases.
I totally agree to what you wrote. Leap is for the conservative. The normal Leap user likely shouldn't care about specific versions of KDE components. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 28/07/16 13:00, Martin Schlander wrote:
Torsdag den 28. juli 2016 11:42:39 skrev Luca Beltrame:
In data giovedì 28 luglio 2016 11:08:59 CEST, Raymond Wooninck ha scritto:
For KDE Applications this situation is even worse as that here in most cases a newer Frameworks and newer Plasma version is required with
Some more points to add to the dicussion: Usually Framework dependencies are per-project (which complicates things), what we have seen historically is that Plasma *may* require a newer Applications version for some functionality (one only case known so far: events shown in the calendar).
That would be a new feature. I don't think we'll see that in the 5.8 branch releases since that branch will only get bugfixes.
So how about a model where:
Leap is released with Plasma 5.8. And only gets upstream Plasma 5.8 bugfix releases via the official update channel.
Frameworks can stay at the initial version. Or it can be upgraded to a newer version if there are very critical bugs or security issues that are fixed - or it can be upgraded at the discretion of the KDE team. Personally I'm willing to gamble on the ABI/API stability of Frameworks. But no point in upgrading just for the sake of upgrading. I assume Ludwig is OK with this too?
Applications can stay at 16.08.x. Or they can be upgraded if Frameworks is upgraded first. But personally I'd prefer applications not to have feature upgrades during the Leap release cycle, as I am a big kdepim user who don't like surprises ;-)
As I see it, Leap users (i.e. stability and predictability afficionados) and the KDE team have a common interest in not messing around with Leap more than necessary. But I could be missing something. We have Tumbleweed and OBS repos for other use cases.
+1 to that model from my side. -- Antonio Larrosa -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Ludwig Nussel schrieb:
Raymond Wooninck schrieb:
On Tuesday, 26 July 2016 15:56:16 CEST Antonio Larrosa wrote:
This mean bringing forward some kde release dates and postponing some openSUSE pre-releases to make everything fit tightly:
Following that schedule means that openSUSE 42.2 would be released including 5.8.1.
In my opinion one important point is being overlooked. We have a LTS version for Plasma, but as far as I know we do not have LTS versions for Frameworks nor Applications.
So we should first discuss and align the maintenance strategy before even discussing the version of these components. Would it be possible to update the Frameworks, Plasma and Application components in Leap 42.2 through the normal maintenance channels (like we have been doing a couple of times for Leap 42.1), or is the maintenance for 42.2 now restricted to pure bugfixes and versions of packages should be kept at the same level as the release ??
Good point. Leap's message is to prefer working components over the latest and greatest and I'd wish that it's default desktop would somehow reflect that spirit too. As such switching to a Plasma LTS release fits the story well. However, planning to have a kind of buggy default desktop and to release an online update for it right when we release 42.2 doesn't. Therefore I'd like to have e.g 5.8.1 on GM if that has the most obvious bugs fixed already. I'd probably rather move some milestone than shipping .0. The update channel technically does not forbid version updates. Still we have to keep the use case of Leap in mind. Therefore I'd rather not repeat such KDE version updates as we had in 42.1. Esp intrusive ones that add new packages, obsolete others and cause build failures etc. So if Plasma, Framework or Applications are developed and released independently, maybe upstream needs to sit together and come up with Framework and Applications releases that fit the Plasma LTS one. All three components together form KDE and the impression people get from it after all. Since we promote KDE as default desktop the impression does rub off on Leap. So it better be a good one.
+1 +1 +1 Martin -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Tuesday 26 of July 2016 15:56:16 Antonio Larrosa wrote:
Hello,
As you know, a few weeks ago KDE announced Plasma 5.8 would be a LTS release. I think the decision to create a LTS release was at least partly caused by our (openSUSE) needs, so I think it's nice of them to decide to do that for us and I think it would benefit both KDE and openSUSE if we included Plasma 5.8 in openSUSE Leap 42.2 . 18 months of upstream support? I'm sure nobody would say no to that.
The problem comes when one looks at the schedules for Plasma and openSUSE Leap releases:
https://community.kde.org/Schedules/Plasma_5 https://en.opensuse.org/openSUSE:Roadmap
The main part of the current schedules is:
2016-08-25: openSUSE 42.2 Beta 1 2016-09-15: KDE 5.8 Repo Freeze 2016-09-21: openSUSE 42.2 Beta 2 - Package freeze 2016-09-29: KDE 5.7.95 LTS (5.8.0 Beta) 2016-10-06: openSUSE 42.2 RC1 2016-10-13: KDE 5.8.0 LTS Release 2016-10-18: openSUSE 42.2 RC2 first week of November 2016: openSUSE 42.2 Release
As you see, there's quite bad timing in there. I've talked with some plasma developers and Ludwig separately trying to move both schedules around in a way that could make it possible to get 5.8.0 in openSUSE 42.2.
I have a proposal that I think (and hope) that will satisfy everyone so I think it's time to move this forward to all involved parties. In that sense, I wrote a very similar mail to the plasma developers and will send it at the same time than this one. I hope you like the proposal and note that I've tried to keep in mind the needs of each project (QtCon/Akademy dates and the desire to have a stable Plasma release on one side, SUSECon/SLE12SP2/other dates and the desire to have a stable openSUSE release on the other).
This mean bringing forward some kde release dates and postponing some openSUSE pre-releases to make everything fit tightly:
2016-09-01: openSUSE 42.2 Beta 1 (this would include the last Plasma release available at that time, 5.7.4 or 5.7.5) 2016-09-08: Plasma 5.8 Repo Freeze (last day of Akademy, maybe that could be moved to freeze the repo just before QtCon?) 2016-09-15: Plasma 5.7.95 LTS (aka 5.8.0 Beta) 2016-09-21: openSUSE 42.2 Beta 2 - Package freeze (with 5.7.95) 2016-09-29: Plasma 5.8.0 LTS Release 2016-10-06: openSUSE 42.2 RC1 (with Plasma 5.8.0) 2016-10-11: Plasma 5.8.1 LTS 2016-10-18: openSUSE 42.2 RC2 (most probably including Plasma 5.8.1 if bugs found and depending on the size of changes) 2016-10-18: Plasma 5.8.2 LTS 2016-11-01: Plasma 5.8.3 LTS First week of November 2016: openSUSE 42.2 Release
Following that schedule means that openSUSE 42.2 would be released including 5.8.1.
This would mean too that we (can I include myself as a kde packager too?
:) ) would have less time to package KDE releases for 42.2 and less time
to test them too since some openSUSE betas would be postponed but RC1 and RC2 would stay at the same dates. Ludwig also mentioned he's willing to shift the Leap schedule a bit more if needed, but for now, the proposal is what's stated above.
So, my question is, would you agree with that? Anybody sees any problem if both projects agree to those changes to their respective schedules?
Please, keep in mind that both projects have needs and requirements, but it would be great to find one solution that benefits both of us and for that, both projects have to give in a little.
I agree also with Raymond. For Plasma IMO is not essential to have 5.8 already in final; we should be able to roll 5.8.1 or .2 into :Update though. (Indeed having it with Leap final would be better, but not that big deal if we miss it). For KF5 most likely at least a few releases after 42.2 release should be in good shape to go into :Update. Later on i'm not optimistic about Plasma compat (e.g. there's an ongoing bug with plasma-framework 5.24 & Plasma 5.6.x wrt missing tray icons). Wrt Applications i can't say; most apps (PIM excluded - i'm still on pre- akonadi PIM, so can't say how are things going there). in recent times don't suffer from (heavy) regressions, so i guess we can see what to do with that. Cheers, Hrvoje
Thanks, -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data martedì 26 luglio 2016 22:59:35 CEST, šumski ha scritto:
Wrt Applications i can't say; most apps (PIM excluded - i'm still on pre- akonadi PIM, so can't say how are things going there). in recent times don't suffer from (heavy) regressions, so i guess we can see what to do with that.
It's mostly a *packaging* effort due to the code moves and dependencies between the new split repositories. I haven't observed big regressions in a while and the new release (16.08) actually fixes a few regressions from 4.x (e.g. the "reindex mail" buttons are back). -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
participants (7)
-
Antonio Larrosa -
Luca Beltrame -
Ludwig Nussel -
Martin Burnicki -
Martin Schlander -
Raymond Wooninck -
šumski