From what I understand, there is a conflict, caused by the following facts:
KDE Plasma’s schedule only has a very short time that the current release (currently 6.6.x) and the former release (6.5.x) are both supported. (Link to schedule)
Fedora’s KDE Plasma maintainers are not planning to backport bugfixes to the former release (say, 6.6.x to 6.5.x) and do not want to have Fedora users run Fedora with unsupported Plasma versions due to security and safety concerns.
From what I understand, this leads to KDE Plasma being updated relatively fast after the release (6.6.0 was published 2026-02-17 and was pushed to Fedora stable on the same day. As a result, all the bugs of 6.6.0 hit every user who updated their distro in time. Since this seem to be quite some bugs, this causes frustration, or people being trained to not update Fedora on a timely manner, or both.
The primary idea proposed in this thread seems to underestimate either the costs of backporting bugfixes or of the security risks that the KDE Plasma maintainers are seeing.
How about a different approach to stay in the boundaries above, but still make more KDE plasma users more happy than they are now: The last 6.5.x bugfix release is still a few weeks away, so technically, there is an overlap of ~4 weeks between 6.6.x and 6.5.x series, even 6.6.2 is published before the last 6.5.x bugfix release. So the 6.y.0 and – if necessary – 6.y.1 and even 6.y.2 release could have way higher karma thresholds (e.g. 20 and 10), accepting that 6.y.0 would never be pushed to stable, and maybe even 6.y.1 wouldn’t. To support testing, get some KDE Test Days announcement to motivate people to beta-test, get the bugs reported and fixed so maybe 6.y.1 or latest 6.y.2 can land in stable with enough stability for most of the users.
Hmm,
That doesn’t sound unreasonable… as a way to create an opportunity for more feedback from users when things are in testing. I would push back on that proposal a little in that the higher karma threshold does need to be timeboxed. If users arent doing the testing and arent reporting back via the karma system, that can’t be a reason to hold back the update forever.
I think its probably fair to say, you want as much testing as you can get, but its never enough.
For comparison, the Fedora GNOME edition has these benefits:
People who rely on Fedora as their daily driver won’t update a Fedora release on day 1, so they can stay on an older version that still gets security updates. (With Fedora KDE, you would need to either selectively update all non-KDE updates – which is only possible if you don’t have auto updates enabled – , or you won’t get any security updates for any software at all).
GNOME’s .0 release usually happens a few weeks before Fedora final freeze (see Fedora schedule and GNOME schedule). As a result, GNOME is tested more by people who update to beta, i.e., who expect things to break and are more willing to report issues.
GNOME’s .1 release is before the Fedora release date. As a result, if anyone updates after Fedora release date, the chances are high that the .1 update has already landed in the repos, so the majority of people will skip the .0 release completely.
(This is not to claim that Fedora GNOME is better than Fedora KDE, just that Fedora fits better to the GNOME schedule than the KDE schedule, which is just rephrased from multiple people pointing it out above)
Fedora GNOME implicitly benefits from Fedora’s schedule. For Fedora KDE, these benefits would need to be explicitly designed (unless the schedule changes).
Why have the karma timeboxed? Since 6.y.1 is released only 1 week after 6.y.0, there is barely enough time for busy people (both RedHat employees and hobbyist volunteers) to properly test it. So it wouldn’t be a loss if 6.y.0 would never make it to stable – unless it got exceptionally positive karma. And it even wouldn’t be that bad if 6.y.1 wouldn’t land either. By putting the higher karma treshold only to the .0 and .1 releases, in combination with their schedule, they are implicitly timeboxed already.
And yes, if not enough people don’t test, then of course we need to find more volunteers.