[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1035056: [pre-approval] plasma-desktop 5.27.X



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.

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)?

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)?

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?

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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: