- Package:
- release.debian.org
- Source:
- release.debian.org
- Submitter:
- Hefee
- Date:
- 2023-05-30 20:36:04 UTC
- Severity:
- normal
- Tags:
Hey,
before invest time, to do the debdiff and all paperwork for Plasma 5.27.X LTS
packages, there's need to be a idea, how to get it into stable.
Currently 5.27.3 on experimental. Upstream is relasing with a fibbonacci
time frame, when stable will be release, we would be at ~5.27.5. I
wanted to ask, if we find a solution together to get the new version
into bookworm. Upstream wants to give bugfix releases over 2 years.
Plasma 5.27 is a LTS branch, that is stable and only bug fixes with be
released with next minor versions. No transitions nor API changes. By
the time the most bug fixes are around multi screen support. From my
point of view users would definitly benefit from these updates with no
negative effect.
Alternatives:
* Using backport is not an option, because upstream is switching to Plasma 6 (based
on Qt6), that will enter in sid soon after bookworm has released.
* extract all bugfixes from Plasma 5.27.X and apply them as patches on
top and remove the version bump. In the end it is a lot more work on
our plate, with no benefit for users. Upstream has much more
problems to understand, that Debian has all bugfixes included.
It is the first time we the KDE manatiner are in this lucky situation
that we can use the LTS releases from upstream. I hope we will find a
good solution together to make the user experince better and not put a
lot of work on yours/ours plate.
The NACK on #1033271 made part of the team quite unmotivated to try it
for Plasma. See the mail thread [1]
Regards,
hefee
Plasma is ~50 pacakges - see a list of packages:
https://salsa.debian.org/qt-kde-team/pkg-kde-dev-scripts/-/blob/master/tierdata/plasma.5.25.0.tier.sh
[1] https://alioth-lists.debian.net/pipermail/pkg-kde-talk/2023-April/003467.html
Hi, we've uploaded Plasma 5.27.5 to experimental and this is the version that we would prefer to have in bookworm instead of 5.27.2. I can only iterate what hefee said before: This is merely a bugfix release and does not add new (build) dependencies or functionality. Plasma 5.27.5 fixes over 100 (!!) bugs that currently exist in bookworm. Backporting bugfixes one by one is not really an option as this would put too much work on both the Qt/KDE and the release team. I hereby ask kindly for approval to upload Plasma 5.27.5 to unstable such that it can and will migrate to bookworm. Plasma 5.27.5 is a suite of 56 source packages in total and we would like to avoid sending 56 unblock/approval requests. The affected packages are: bluedevil breeze breeze-grub breeze-gtk breeze-plymouth drkonqi flatpak-kcm kactivitymanagerd kde-cli-tools kdecoration kde-gtk-config kdeplasma-addons kgamma5 khotkeys kinfocenter kmenuedit kpipewire kscreen kscreenlocker ksshaskpass ksystemstats kwallet-pam kwayland-integration kwin kwrited layer-shell-qt libkscreen libksysguard milou oxygen oxygen-sounds plasma-bigscreen plasma-browser-integration plasma-desktop plasma-discover plasma-disks plasma-firewall plasma-integration plasma-nano plasma-nm plasma-pa plasma-remotecontrollers plasma-sdk plasma-systemmonitor plasma-thunderbolt plasma-vault plasma-welcome plasma-workspace plasma-workspace-wallpapers plymouth-kcm polkit-kde-agent-1 powerdevil qqc2-breeze-style sddm-kcm systemsettings xdg-desktop-portal-kde
Hi, Please read the freeze policy [2] and the FAQ [3] very carefully and make sure your request meets the requirements of this phase of the freeze and make sure you can answer every relevant question from the FAQ. Please only pursue if you convinced the answer is yes. What does that mean (sorry, I don't have the energy to look this up, too many unblock requests to process)? So you consider bumping 5.27.2 to 5.27.5 a targeted fix? Would you request the same in a stable point update (because that's about the same level at this phase of the release)? [From FAQ] can you point at an upstream document that explains their policy? I think you know by now, this fits extremely bad with the way the Freeze is handled as we review everything and need to watch that everything migrates. We're not going to give a set of key packages a cart blanch this late in the freeze especially when we've NACK-ed already easier things. E.g. although we're convinced the MariaDB unblock [4] really had all best intentions and we hate to deny unblocks, it contained a bunch of changes not meeting the freeze policy. We're frozen to ensure stability and no surprises. The freeze policy is not ment to manage packages (that's up to the maintainers), it's meant to ensure we can manage the release process. In this particular case, we also don't have tools to ensure the set remains coherent, does the set ensure they migrate as a whole? If not, how bad would it be when some pieces migrate and others can't before the release? For your info, I'm going to try hard to ensure KDE and plasma are going to be removed from the key package set for trixie, which means that you don't need our involvement until much later in the trixie freeze. However, that won't help you anymore this time around because a) that key package set definition change isn't going to happen before the release and b) it's too late in the freeze to matter anymore. Paul [2] https://release.debian.org/testing/freeze_policy.html [3] https://release.debian.org/testing/FAQ.html [4] https://bugs.debian.org/1033811
It’s really disappointing that the only reason for blocking Plasma 5.27.5 and Frameworks 5.104 is that there’s “too many packages”. KDE upstream has stopped feature development for Plasma 5.x and Frameworks 5.x with the releases of Plasma 5.27.0 and Frameworks 5.100, because the focus has completely switched to developing Plasma 6.0 and Frameworks 6.0 [1] [this link also explains the Fibonacci release cycle that you asked about]. That means Plasma 5.27.x and Frameworks 5.1xx are strictly only bug fix releases, they contain absolutely no new features and no major regressions have been reported in the newer versions. Just check the changelogs for every Plasma release since 5.27.2 and every Frameworks release since 5.103 (the versions Testing is stuck on), there have been *hundreds* of bugs fixed since. Cherry-picking fixes for the most prominent crashes just isn’t practical considering especially how many bugs were fixed in Plasma 5.27.3 alone. I’d like to remind you that GNOME 43.4 was allowed to migrate recently; why does GNOME get special treatment and KDE has to stay stuck on an older, buggier version? Debian KDE users would strongly appreciate you changing your stance and allowing the best versions to be included on release. If you still are not convinced on allowing these to be unblocked, would you at least consider allowing them to migrate for the Debian 12.1 point release? Again, I’d like to remind you that these are long-term support releases, they strictly fix bugs and contain no new features. There are absolutely no downsides to allowing them to migrate so they can be in Debian 12. Thank you for your consideration and your hard work maintaining Debian. [1] https://community.kde.org/Schedules/Plasma_5 - “This is the last Plasma 5 release and will receive bugfixes only, no new features. The bugfixes are intended to continue being integrated into 5.27 until a first version of Plasma 6 can be released (and might continue longer).”
Dear x s, Le 16 mai 2023 09:37:32 GMT+02:00, x s <kittenlive@icloud.com> a écrit : we understand that users are eager to see Plasma updated, we (the KDE packaging team) are too, thanks for your feedback. I'd prefer that we discuss the way to make it happen between the KDE packaging team and the release team in a dispassionate way though. Yes, we (the KDE packaging team) would very much like to do that if it's not possible to get an unblock before the release. No guarantee that it can fit into our release and stable updates processes though, so no guarantees. Stay tuned and please let us think about the implications and manage the topic in a way that is appropriate for a stable Debian release. All the best, -- Aurélien
Dear Paul,
Le dimanche 14 mai 2023, 22:05:19 CEST Paul Gevers a écrit :
LTS
policy requirements to the letter.
What we’re asking for is an exception because we think the current policy
isn’t helping with release quality for a project the size and complexity of
Plasma and with such a level of upstream activity.
As Patrick wrote there are over a hundred bugs fixed in 5.27.3, .4 and .5
releases that we’re currently not shipping in bookworm.
We don’t have the personpower to backport all these fixes to 5.27.2
individually and even if we did it would be a questionable option.
We consider the risk of introducing new bugs by not shipping all upstream
changes to be higher than shipping complete point releases. In addition we
would be creating a Debian-specific version of Plasma unsupported by upstream,
in parallel to their very own bugfix release branch that they maintain with a
very close target to ours : only bugfixes to avoid regressions.
So the remaining options we can think of are :
- Ship bookworm with Plasma as it is : good for the release policy and our
team’s workload, certainly bad for our users and the image of Plasma on
Debian.
- Remove Plasma from stable : not doable for bookworm as it is in the
essential set like you wrote below, not a good move for Debian anyway I hope
we would agree.
- Ship the point releases to stable : won’t follow the freeze policy to the
letter, manageable work on our side, certainly good for our users besides
possible regressions introduced upstream, regressions will be looked at by
upstream if they happen.
Each point release is made further away in time from the previous, as Plasma
5.27 LTS stabilizes.
We consider it a better option for bookworm, being overall a big collection of
fixes. We don’t pretend it meets the targeted fix policy for each and every
commit that goes in.
And yes, we would like to be able to ship Plasma point releases to stable.
This hasn’t been discussed with the relevant teams yet.
You may find the Plasma release page at [1] which only says :
This is the last Plasma 5 release and will receive bugfixes only, no new
features. The bugfixes are intended to continue being integrated into 5.27
until a first version of Plasma 6 can be released (and might continue longer).
[1] https://community.kde.org/Schedules/Plasma_5#LTS_releases
So they commit on putting only bugfixes in their LTS releases, but not only
targeted bugfixes like we do.
I don’t want to compare situations but would like to discuss the merits of
pushing Plasma point releases in bookworm.
And we do value your work on the release process and share the goal of
releasing a stabilized Debian. We are not convinced that the process is
helping us reaching that goal for Plasma, however.
so we could ensure package sets migrate as a whole. Certainly not something I
could address on my own but I would be willing to contribute to the initiative
if such a tool was being worked on.
As for Plasma not migrating as a whole with the current tooling: we’ve
discussed the issue with hefee and Patrick and we consider the risk of
introducing specific issues to be very low. It’s all bugfixes after all, so
the packages not migrating won’t get their own bugfixes.
That’s a good thing, thank you for that, but not what we’re after in this
unblock request.
All the best,
--
Aurélien
Hi, People that read a lot of my replies will recognize it when I say that I don't care about the letter, but about the intent behind it. Is that complete list of bugs available somewhere, such that we can get an impression one the type of bugs that are fixed? I guess it's: https://kde.org/announcements/changelogs/plasma/5/5.27.2-5.27.3/ and likewise for the other versions. I think we are aligned on that. But having said that, are there bug you have particularly on your radar? And would it be an option to not cherry pick backport bug fixes, but cherry pick packages with their bug fixes? @ all, I'll not be available the next 5 days because of holidays. I wish I had more time to answer now, because the Full Freeze is approaching fast. By all means continue the discussion while I'm gone. Paul
There's one week left until bookworm goes into full freeze, and there's been no update here so I'm assuming KDE Plasma 5.27.5 won't be unblocked for bookworm unless a miracle happens, so I wanted to ask, just as an average user who's not involved at all in Debian packaging - How possible is it for Plasma 5.27.5 (or probably 5.27.6 which will be out just shortly after bookworm comes out in June [1]) to make it into the Debian 12.1 point release? Hope your holidays were enjoyable! Thank you for all the work you do. [1] https://community.kde.org/Schedules/Plasma_5#Future_releases - 5.27.6 releases on June 20th, ten days after bookworm does on June 10th
Dear Paul, Le mardi 16 mai 2023, 22:20:37 CEST Paul Gevers a écrit : I don’t have particular bugs in mind, I think the selection that upstream makes of bugs that deserve a fix in their stable 5.27 branch makes sense for us to follow. You can get an idea of the kind of bugs fixed at [0]. There’s no « fixed in version » field in their bugzilla so I took the list of bugs reported against 5.27.2..5.27.4 marked as fixed as an approximation. [0] https://bugs.kde.org/buglist.cgi?query_format=advanced&resolution=FIXED&version=5.27.2&version=5.27.3&version=5.27.4 Also note that some package (build)depend on other packages in the Plasma set having the exact same upstream version. While not a good argument in itself that still means we would need to do some version-fu to make the package cherry-pick option work. I’ve made some statistics about the 56-package Plasma set and between 5.27.2 (in testing) and 5.27.5 (in experimental) we have : - 4 packages with no change besides the version bump - 20 packages with transaltion-only commits (upstream never mentions these in their release notes) - 32 remaining packages having code fixes and mentioned in the release note, including 5 not having an explicit bug id linked Please find the details in the table below. Best, -- Aurélien | package | has | has non-transl | mentioned in | bug fixed in | | | translations | commits | rel notes | rel notes | |---------------------------|--------------|----------------|--------------|--------------| |breeze-grub | | | | | |breeze-plymouth | | | | | |layer-shell-qt | | | | | |oxygen-sounds | | | | | |kactivitymanagerd | x | | | | |kdecoration | x | | | | |kgamma5 | x | | | | |khotkeys | x | | | | |kmenuedit | x | | | | |ksshaskpass | x | | | | |ksystemstats | x | | | | |milou | x | | | | |oxygen | x | | | | |plasma-bigscreen | x | | | | |plasma-browser-integration | x | | | | |kwrited | x | | | | |plasma-disks | x | | | | |plasma-firewall | x | | | | |plasma-nano | x | | | | |plasma-systemmonitor | x | | | | |plasma-thunderbolt | x | | | | |plasma-vault | x | | | | |plasma-workspace-wallpapers| x | | | | |plymouth-kcm | x | | | | |qqc2-breeze-style | | x | x | | |drkonqi | x | x | x | | |kwallet-pam | x | x | x | | |libksysguard | x | x | x | | |sddm-kcm | x | x | x | | |breeze-gtk | | x | x | x | |bluedevil | x | x | x | x | |breeze | x | x | x | x | |flatpak-kcm | x | x | x | x | |kde-cli-tools | x | x | x | x | |kde-gtk-config | x | x | x | x | |kdeplasma-addons | x | x | x | x | |kinfocenter | x | x | x | x | |kpipewire | x | x | x | x | |kscreen | x | x | x | x | |kscreenlocker | x | x | x | x | |kwayland-integration | x | x | x | x | |kwin | x | x | x | x | |libkscreen | x | x | x | x | |plasma-desktop | x | x | x | x | |plasma-discover | x | x | x | x | |plasma-integration | x | x | x | x | |plasma-nm | x | x | x | x | |plasma-pa | x | x | x | x | |plasma-remotecontrollers | x | x | x | x | |plasma-sdk | x | x | x | x | |plasma-welcome | x | x | x | x | |plasma-workspace | x | x | x | x | |polkit-kde-agent-1 | x | x | x | x | |powerdevil | x | x | x | x | |systemsettings | x | x | x | x | |xdg-desktop-portal-kde | x | x | x | x |
Hi all, [For those following at home, I had multiple live discussions with Aurélien at the Debian Reunion Hamburg.] Ok, it's terribly late but let's go for this then. You'll need to help a bit more though. You want the full set to migrate together, so please check the status of the upload you did yesterday and let me know when everything is ready. That means that no package should be blocked on anything except age and the freeze. Piuparts and autopkgtest runs must have finished and when finished neither must block migration. Did you mention you have a web page for that already, can you share the link? Also please prepare the correct set of hints, they need to be in the form of: unblock package-name/version-in-unstable Paul
Le dimanche 28 mai 2023, 08:26:16 CEST Paul Gevers a écrit : ❤❤❤ Yes, that is [0]. [0] https://deb.li/plasma The packages on the dashboard are sorted by layers of build dependencies then alphabetically in each layer. So you will find the packages further in the dependency tree at the bottom, and not all built yet. The same dashboard for bookworm incorrectly reports breeze-grub as sucessfully built for mips64el and s390x but this was not the case. We I don’t think we have the equivalent for autopkgtests / puiparts so I’ll check these manually. That would be the list at the bottom. We will confirm when all builds / tests have passed. Cheers -- Aurélien unblock bluedevil/4:5.27.5-2 unblock breeze-grub/5.27.5-2 unblock breeze-plymouth/5.27.5-2 unblock drkonqi/5.27.5-2 unblock flatpak-kcm/5.27.5-2 unblock kactivitymanagerd/5.27.5-2 unblock kdecoration/4:5.27.5-2 unblock kgamma5/5.27.5-2 unblock kinfocenter/4:5.27.5-2 unblock kmenuedit/4:5.27.5-2 unblock kpipewire/5.27.5-3 unblock ksshaskpass/4:5.27.5-2 unblock kwallet-pam/5.27.5-2 unblock kwayland-integration/5.27.5-2 unblock kwrited/4:5.27.5-2 unblock layer-shell-qt/5.27.5-2 unblock libkscreen/4:5.27.5-2 unblock libksysguard/4:5.27.5-2 unblock milou/4:5.27.5-2 unblock oxygen-sounds/4:5.27.5-2 unblock plasma-discover/5.27.5-2 unblock plasma-disks/5.27.5-2 unblock plasma-firewall/5.27.5-2 unblock plasma-nano/5.27.5-2 unblock plasma-nm/4:5.27.5-2 unblock plasma-pa/4:5.27.5-2 unblock plasma-sdk/5.27.5-2 unblock plasma-thunderbolt/5.27.5-2 unblock plasma-welcome/5.27.5-2 unblock plasma-workspace-wallpapers/4:5.27.5-2 unblock plymouth-kcm/5.27.5-2 unblock polkit-kde-agent-1/4:5.27.5-2 unblock qqc2-breeze-style/5.27.5-2 unblock sddm-kcm/4:5.27.5-2 unblock xdg-desktop-portal-kde/5.27.5-2 unblock breeze/4:5.27.5-2 unblock kde-gtk-config/4:5.27.5-2 unblock kscreen/4:5.27.5-2 unblock kscreenlocker/5.27.5-2 unblock ksystemstats/5.27.5-2 unblock oxygen/4:5.27.5-2 unblock plasma-systemmonitor/5.27.5-2 unblock plasma-vault/5.27.5-2 unblock breeze-gtk/5.27.5-2 unblock kwin/4:5.27.5-3 unblock plasma-integration/5.27.5-2 unblock plasma-workspace/4:5.27.5-2 unblock kde-cli-tools/4:5.27.5.1-2 unblock kdeplasma-addons/4:5.27.5-2 unblock khotkeys/4:5.27.5-2 unblock plasma-bigscreen/5.27.5-2 unblock plasma-browser-integration/5.27.5-2 unblock plasma-desktop/4:5.27.5-2 unblock plasma-remotecontrollers/5.27.5-2 unblock powerdevil/4:5.27.5-2 unblock systemsettings/4:5.27.5-2
Hi, Le dimanche 28 mai 2023, 14:13:48 CEST Aurélien COUDERC a écrit : All packages are now built in unstable, all puipart tests pass, we don’t have autopkgtests for this package set. For the record in the 100+ bugs fixed we have several shell desktop, screen management crashers and app crashers due to screen management that we would highly prefer having in for bookworm. I’ve included the fix for RC bug #1034215 where the KDE crash reporter drkonqi wouldn’t start on application crashes. The Plasma 5.27 branch is going to be maintained upstream for a foreseeable future so if I can convince the stable release managers to do the same, I plan to push future Plasma bugfix releases to stable after the bookworm release. I confirm the list of unblock hints from my previous email below. Thanks, -- Aurélien unblock bluedevil/4:5.27.5-2 unblock breeze-grub/5.27.5-2 unblock breeze-plymouth/5.27.5-2 unblock drkonqi/5.27.5-2 unblock flatpak-kcm/5.27.5-2 unblock kactivitymanagerd/5.27.5-2 unblock kdecoration/4:5.27.5-2 unblock kgamma5/5.27.5-2 unblock kinfocenter/4:5.27.5-2 unblock kmenuedit/4:5.27.5-2 unblock kpipewire/5.27.5-3 unblock ksshaskpass/4:5.27.5-2 unblock kwallet-pam/5.27.5-2 unblock kwayland-integration/5.27.5-2 unblock kwrited/4:5.27.5-2 unblock layer-shell-qt/5.27.5-2 unblock libkscreen/4:5.27.5-2 unblock libksysguard/4:5.27.5-2 unblock milou/4:5.27.5-2 unblock oxygen-sounds/4:5.27.5-2 unblock plasma-discover/5.27.5-2 unblock plasma-disks/5.27.5-2 unblock plasma-firewall/5.27.5-2 unblock plasma-nano/5.27.5-2 unblock plasma-nm/4:5.27.5-2 unblock plasma-pa/4:5.27.5-2 unblock plasma-sdk/5.27.5-2 unblock plasma-thunderbolt/5.27.5-2 unblock plasma-welcome/5.27.5-2 unblock plasma-workspace-wallpapers/4:5.27.5-2 unblock plymouth-kcm/5.27.5-2 unblock polkit-kde-agent-1/4:5.27.5-2 unblock qqc2-breeze-style/5.27.5-2 unblock sddm-kcm/4:5.27.5-2 unblock xdg-desktop-portal-kde/5.27.5-2 unblock breeze/4:5.27.5-2 unblock kde-gtk-config/4:5.27.5-2 unblock kscreen/4:5.27.5-2 unblock kscreenlocker/5.27.5-2 unblock ksystemstats/5.27.5-2 unblock oxygen/4:5.27.5-2 unblock plasma-systemmonitor/5.27.5-2 unblock plasma-vault/5.27.5-2 unblock breeze-gtk/5.27.5-2 unblock kwin/4:5.27.5-3 unblock plasma-integration/5.27.5-2 unblock plasma-workspace/4:5.27.5-2 unblock kde-cli-tools/4:5.27.5.1-2 unblock kdeplasma-addons/4:5.27.5-2 unblock khotkeys/4:5.27.5-2 unblock plasma-bigscreen/5.27.5-2 unblock plasma-browser-integration/5.27.5-2 unblock plasma-desktop/4:5.27.5-2 unblock plasma-remotecontrollers/5.27.5-2 unblock powerdevil/4:5.27.5-2 unblock systemsettings/4:5.27.5-2
Hi, an (in some way) outstanders point of view for this discussion. Am 16.05.23 um 09:37 schrieb x s: It's disappointing that KDE people like this do not care at all about established rules and just start lobbying people because of their usually clueless userbase I observe on mailing list... Which is basically the same for many packages. I am njust going to talk about another prominent free software for desktops: LibreOffice (which I "normally" don't even use but maintain) Same for LibreOffice for example. With the difference that the 7.4.x branch is dead basically now (https://wiki.documentfoundation.org/ReleasePlan/7.4) but also has "Only important bug fixes, and l10n improvements". Also quite a sh*load of bugfixes. See [2] I could have uploaded 7.4.7 two weeks ago, which would have even saved a last minute upload to fix two security issues because they were fixed upstream in that version Still I followed the freze and didn't upload 7.4.6 and 7.4.7. So should KDE and so should anyone. I could say "Why does KDE get special treatment and LibreOffice has to stay stuck on an older, buggier version? Debian LibreOffice users would strongly appreciate you changing your stance and allowing the best versions to be included on release." See the problem? (actually I complained about that double morable and on doing this in effect in a secret cabal meeting yesterday on IRC) > If you still are not convinced on allowing these to be unblocked, would you at least consider allowing them to migrate for the Debian 12.1 point release? Again, I’d like to remind you that these are long-term support releases, they strictly fix bugs and contain no new features. There are absolutely no downsides to allowing them to migrate so they can be in Debian 12. I definitely have learned from this and will refer to this bug next freeze and get the latest LibreOffice in. (And try to get it updated in 12.1). There's no reason to deny that given this (imminent) approval of 50 source packages compared to one. All the other parameters are the same. Regards, Rene [1] https://wiki.documentfoundation.org/ReleasePlan/7.4 [2] https://wiki.documentfoundation.org/Releases/7.4.6/RC1#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.6/RC2#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.7/RC1#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.7/RC2#List_of_fixed_bugs
Hi, I checked as well, and it seems the set is ready to migrate. I have unblocked them. Please inform us when not everything migrated. Paul