Bug#1035056: [pre-approval] plasma-desktop 5.27.X
Dear Paul,
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
> 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.
All the best,
--
Aurélien
Reply to: