#96 Consider applying Fedora policy for KDE Plasma to EPEL
Closed: Fixed 2 years ago by ngompa. Opened 2 years ago by ngompa.

The Fedora KDE SIG now maintains KDE Plasma for RHEL/CentOS in EPEL starting with RHEL 8. We currently ship Plasma 5.18, but @tdawson is rebasing EPEL 8 to Plasma 5.22 as part of updating Plasma to run on Qt 5.15 in RHEL 8.

As the KDE SIG is already tracking and maintaining the latest version of KDE Plasma for Fedora, we should consider doing that for EPEL as well (up until the next EPEL branch is available). This should simplify maintenance efforts and make it easier for us to collaborate with upstream to support our platforms.

What does everyone think on this?

Metadata Update from @ngompa:
- Issue tagged with: epel

2 years ago

Maybe we could do "latest minor point release to latest minor point release" for EPEL to get mostly stable but almost current KDE packages. If something major breaks in EPEL and KDE upstream won't fix it in the previous point release then we can consider updating faster.

Fedora: 5.22.x -> 5.23.0
EPEL: 5.21.5 -> 5.22.5 (skips all .1-4 point releases)

Seems like shipping the latest KDE is not always workable if there are dependency issues, so maybe adjust the wording to reflect our dependence on non-EPEL packages?

"EPEL Next should track the latest KDE Plasma, and we should try and get any needed dependencies in Stream updated as necessary. EPEL should track the latest KDE Plasma that is compatible with the available dependencies".

EPEL is not Fedora, meaning it has a longer lifetime. It's users expect it not to change. That is part of the EPEL policy.

The reason we are able to do a major update that I'm doing is due to the qt5 update that is coming out with RHEL 8.5. That allows us to update all those KDE Plasma desktop packages that are dependent on newer versions of qt5.

With that update I am following EPEL policies in announcing that the changes are coming and giving people time to test and try things out.

I am not against updating KDE Plasma in EPEL. I was originally thinking of once a year giving it a try, seeing which packages would update with the given qt5. But certainly not trying to keep pace with Fedora's updates. And always with plenty of announcement and feedback from the users.

Doing this once a year may make sense too. We could synchronize with the spring releases, barring anything that requires us to bump up mid-year. That means the version of Plasma we ship with Fedora Linux 36 would be synced to EPEL, then the one in Fedora Linux 38, etc.

This also aligns properly for major version releases, since they happen in May every three years (e.g. RHEL 9 releases in May next year).

We've agreed today that we'll go with the following policy:

  • We no longer track Plasma LTS, as it is ineffective and poorer user experience than the latest KDE Plasma.
  • Plasma releases will be synchronized from Fedora to EPEL after each spring release (e.g., F36, F38, and so on)
  • RHEL coordination for Qt will be included as part of this effort to align to spring releases
  • Best-effort attempt to backport fixes from future stable releases as needed, but if not possible, rebasing Plasma remains an option.

@tdawson will formally codify this somewhere so that everyone is on the same page about Plasma in EPEL.

Metadata Update from @ngompa:
- Issue assigned to tdawson
- Issue set to the milestone: Plasma 5.22

2 years ago

I have added this to the KDE/EPEL wiki page. Please look and see if I got this right.


If it looks good, then we can close this issue. If I missed something, or wrote something in a non-clear way, please let me know.

Metadata Update from @ngompa:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.