Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1035056: [pre-approval] plasma-desktop 5.27.X
13 views
Skip to first unread message
Hefee
Apr 28, 2023, 9:40:04 AM4/28/23
to
Package: release.debian.org
Severity: normal
User: release.d...@packages.debian.org
Usertags: pu
X-Debbugs-Cc: plasma-...@packages.debian.org, pkg-kde-talk%40alioth-lists.debian.net, he...@debian.org
Control: affects -1 + src:plasma-desktop
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
Severity: normal
User: release.d...@packages.debian.org
Usertags: pu
X-Debbugs-Cc: plasma-...@packages.debian.org, pkg-kde-talk%40alioth-lists.debian.net, he...@debian.org
Control: affects -1 + src:plasma-desktop
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
Patrick Franz
May 11, 2023, 7:30:05 PM5/11/23
to
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
--
Med vänliga hälsningar
Patrick Franz
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
--
Med vänliga hälsningar
Patrick Franz
x s
May 16, 2023, 3:50:04 AM5/16/23
to
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).”
Aurélien COUDERC
May 16, 2023, 4:30:05 AM5/16/23
to
Dear x s,
Le 16 mai 2023 09:37:32 GMT+02:00, x s <kitte...@icloud.com> a écrit :
>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”.
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.
>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.
These were 2 packages : gnome-shell and mutter. We're talking 50+ packages for Plasma so it's nothing comparable. Paul raised some valid concerns in that regard and we're preparing a response.
>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.
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
Le 16 mai 2023 09:37:32 GMT+02:00, x s <kitte...@icloud.com> a écrit :
>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”.
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.
>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.
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
Aurélien COUDERC
May 16, 2023, 7:40:07 AM5/16/23
to
Dear Paul,
Le dimanche 14 mai 2023, 22:05:19 CEST Paul Gevers a écrit :
> Control: tags -1 moreinfo
>
> Hi,
> 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.
we know the freeze policy and we know our request doesn’t meet the freeze
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.
> > Currently 5.27.3 on experimental. Upstream is relasing with a fibbonacci
> > time frame,
>
> What does that mean (sorry, I don't have the energy to look this up, too
> many unblock requests to process)?
Each point release is made further away in time from the previous, as Plasma
5.27 LTS stabilizes.
> > 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.
>
> 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)?
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.
> > 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.
>
> [From FAQ] can you point at an upstream document that explains their policy?
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.
> > Plasma is ~50 pacakges - see a list of packages:
>
> 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.
I don’t want to compare situations but would like to discuss the merits of
pushing Plasma point releases in bookworm.
> 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.
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.
> 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?
Such a tool would be very useful in this situation, (and for KDE Frameworks)
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.
> 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.
That’s a good thing, thank you for that, but not what we’re after in this
unblock request.
Le dimanche 14 mai 2023, 22:05:19 CEST Paul Gevers a écrit :
> Control: tags -1 moreinfo
>
> Hi,
>
> On 28-04-2023 15:29, Hefee wrote:
> > 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.
>
> Please read the freeze policy [2] and the FAQ [3] very carefully and
> On 28-04-2023 15:29, Hefee wrote:
> > 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.
>
> 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.
we know the freeze policy and we know our request doesn’t meet the freeze
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.
> > Currently 5.27.3 on experimental. Upstream is relasing with a fibbonacci
> > time frame,
>
> many unblock requests to process)?
Each point release is made further away in time from the previous, as Plasma
5.27 LTS stabilizes.
> > 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.
>
> request the same in a stable point update (because that's about the same
> level at this phase of the release)?
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.
> > 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.
>
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).
So they commit on putting only bugfixes in their LTS releases, but not only
targeted bugfixes like we do.
> > Plasma is ~50 pacakges - see a list of packages:
>
> 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.
I don’t want to compare situations but would like to discuss the merits of
pushing Plasma point releases in bookworm.
> 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.
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.
> 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?
Such a tool would be very useful in this situation, (and for KDE Frameworks)
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.
> 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.
That’s a good thing, thank you for that, but not what we’re after in this
unblock request.
Paul Gevers
May 16, 2023, 4:30:05 PM5/16/23
to
Hi,
On 16-05-2023 13:37, Aurélien COUDERC wrote:
> Le dimanche 14 mai 2023, 22:05:19 CEST Paul Gevers a écrit :
>> On 28-04-2023 15:29, Hefee wrote:
> we know the freeze policy and we know our request doesn’t meet the freeze
> policy requirements to the letter.
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.
> 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.
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.
> 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.
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
On 16-05-2023 13:37, Aurélien COUDERC wrote:
> Le dimanche 14 mai 2023, 22:05:19 CEST Paul Gevers a écrit :
>> On 28-04-2023 15:29, Hefee wrote:
> we know the freeze policy and we know our request doesn’t meet the freeze
> policy requirements to the letter.
don't care about the letter, but about the intent behind it.
> 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.
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.
> 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.
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
Aurélien COUDERC
May 27, 2023, 4:51:46 PM5/27/23
to
Dear Paul,
Le mardi 16 mai 2023, 22:20:37 CEST Paul Gevers a écrit :
> > 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.
>
> 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?
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 |
Le mardi 16 mai 2023, 22:20:37 CEST Paul Gevers a écrit :
> > 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.
>
> 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?
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 |
Paul Gevers
May 28, 2023, 2:41:49 AM5/28/23
to
Control: tags -1 confirmed moreinfo
Hi all,
[For those following at home, I had multiple live discussions with
Aurélien at the Debian Reunion Hamburg.]
On 27-05-2023 22:44, Aurélien COUDERC wrote:
> 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.
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
Hi all,
[For those following at home, I had multiple live discussions with
Aurélien at the Debian Reunion Hamburg.]
On 27-05-2023 22:44, Aurélien COUDERC wrote:
> 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.
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
Aurélien COUDERC
May 28, 2023, 8:20:34 AM5/28/23
to
Le dimanche 28 mai 2023, 08:26:16 CEST Paul Gevers a écrit :
> Control: tags -1 confirmed moreinfo
>
> Hi all,
>
> [For those following at home, I had multiple live discussions with
> Aurélien at the Debian Reunion Hamburg.]
>
> On 27-05-2023 22:44, Aurélien COUDERC wrote:
> > 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.
>
> 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?
Yes, that is [0].
> Control: tags -1 confirmed moreinfo
>
> Hi all,
>
> [For those following at home, I had multiple live discussions with
> Aurélien at the Debian Reunion Hamburg.]
>
> On 27-05-2023 22:44, Aurélien COUDERC wrote:
> > 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.
>
> 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?
[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.
> Also please prepare the correct set of hints, they need to be in the
> form of:
> unblock package-name/version-in-unstable
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
Aurélien COUDERC
May 29, 2023, 2:10:05 AM5/29/23
to
Control: tags -1 -moreinfo
Hi,
Le dimanche 28 mai 2023, 14:13:48 CEST Aurélien COUDERC a écrit :
> Le dimanche 28 mai 2023, 08:26:16 CEST Paul Gevers a écrit :
>
> [0] https://deb.li/plasma
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.
> > Also please prepare the correct set of hints, they need to be in the
> > form of:
> > unblock package-name/version-in-unstable
I confirm the list of unblock hints from my previous email below.
Thanks,
Hi,
Le dimanche 28 mai 2023, 14:13:48 CEST Aurélien COUDERC a écrit :
> Le dimanche 28 mai 2023, 08:26:16 CEST Paul Gevers 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.
> > Also please prepare the correct set of hints, they need to be in the
> > form of:
> > unblock package-name/version-in-unstable
Thanks,
Rene Engelhard
May 29, 2023, 3:20:04 AM5/29/23
to
Hi,
an (in some way) outstanders point of view for this discussion.
Am 16.05.23 um 09:37 schrieb x s:
established rules and just start lobbying people because of their
usually clueless userbase I observe on mailing list...
I am njust going to talk about another prominent free software for
desktops: LibreOffice (which I "normally" don't even use but maintain)
>
> 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.
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’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.
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
(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
an (in some way) outstanders point of view for this discussion.
Am 16.05.23 um 09:37 schrieb x s:
> 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”.
It's disappointing that KDE people like this do not care at all about
> 5.27.5 and Frameworks 5.104 is that there’s “too many packages”.
established rules and just start lobbying people because of their
usually clueless userbase I observe on mailing list...
>
> 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].
Which is basically the same for 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].
I am njust going to talk about another prominent free software for
desktops: LibreOffice (which I "normally" don't even use but maintain)
>
> 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.
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’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.
"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?
included on release."
(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.
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
0 new messages