Bug 2063524

We're already well into the RHEL 8 cycle (BZs are now implicitly targeting 8.7) so new features are no longer really a priority at the moment. Even if we were still supporting KDE in RHEL, we'd still keep the version fixed (like we do with GNOME); this BZ is for KDE 5.25 which isn't even released yet, so that makes justification even harder.

Combine all that with the chance of introducing regressions to our customers and the limited capacity we have in our SST (both development & QE), I don't think it makes sense to take this (or bug 2063526) on.

If you plan on still building this newer version of KDE, you can still create an EPEL-specific branch of the needed dependencies (or even create a COPR).

Do upgrading the wayland and wayland-protocols packages really cause regressions? That's never been my impression in seeing how these libraries have evolved in Fedora for the past several releases.

I've been filing these requests well in advance because I'm trying to align the KDE SIG's schedules, RHEL point release release schedules, and KDE Plasma schedules (https://community.kde.org/Schedules/Plasma_5). The KDE SIG tries to do one KDE Plasma upgrade a year, because we don't have the ability to maintain a single version forever.

We can't really do EPEL packages of this because EPEL does not allow overriding base packages.

(In reply to Neal Gompa from comment #2)
> Do upgrading the wayland and wayland-protocols packages really cause
> regressions? That's never been my impression in seeing how these libraries
> have evolved in Fedora for the past several releases.

For Wayland specifically, one example of a worrying regression we've seen is https://gitlab.freedesktop.org/xorg/xserver/-/issues/1283 . From the Pagure issue that's linked there was also an explicit request to have wayland and wayland-protocols updated in sync, which is why I closed bug 2063526 in tandem.

It's good to realize that regressions in Fedora and RHEL are handled differently: in Fedora, if we have such a regression, we can ask people to report the issue and then wait for an update and/or revert to an older version of the package. In RHEL, part of the customer experience is to make sure such regressions never even get to them in the first place -that's part of our promise on stability, certainly on Y-stream updates. It requires us to be very cautious on any change we make and justify the need for it.

> I've been filing these requests well in advance because I'm trying to align
> the KDE SIG's schedules, RHEL point release release schedules, and KDE
> Plasma schedules (https://community.kde.org/Schedules/Plasma_5). The KDE SIG
> tries to do one KDE Plasma upgrade a year, because we don't have the ability
> to maintain a single version forever.

Well, "well in advance" depends a bit on what distribution you're talking about.

For RHEL 8 specifically: getting in new features (especially upgrading a whole desktop environment) and doing package rebases at this point is really not feasible, unless it can be justified from a business/customer perspective. This constraint applies even for requests from RH teams internally. Asking to do this rebase to enable having the latest version of KDE in EPEL is an argument that just doesn't meet that.

For RHEL 9: I'm aware of those other BZs and I'm having discussions how to handle these internally. The same story applies there: we want to support the community in their efforts, but rebases need to go through the same process all the same. Accepting a rebase is not justifiable if it means we introduce a regression for one of our customers in RHEL