Define a process for handling release blocking bugs present for a long time #886

New issue

Open

opened 2026-03-23 14:05:12 +00:00 by kparal · 1 comment

kparal commented

2026-03-23 14:05:12 +00:00

Owner

This bug (voting ticket) is an example of a bug that should be a release blocker, but we've been shipping with it for a long time, and so we're reluctant to accept it as a blocker for the upcoming release. We can't waive bugs like these forever, we need a plan. Let's come up with some process/plan what to do with bugs like these.

Here's my idea:

Accept it as a blocker, because it violates release criteria. Waive it as hard to fix, that makes it a blocker for the next release (FN+1). Inform the maintainers that this is accepted as a blocker in 6 months' time. That gives that sufficient time to fix it. If the problem is still not fixed for the next release, waive it as hard to fix again, moving it to FN+2. If the story repeats (still broken in FN+2), propose dropping of the release criterion (or carving some exceptions in it).

Because if all of these are true:
a) we consider the broken functionality to be release-critical (a blocker)
b) the bug has been present for a long time already
c) we've waited for 1 more year for a fix and it's still not available
d) we're willing to release Fedora every time anyway

then it's most probably the right time to stop considering it a release blocker.

Thoughts?

[This bug](https://bugzilla.redhat.com/show_bug.cgi?id=2448283) ([voting ticket](https://pagure.io/fedora-qa/blocker-review/issue/2078)) is an example of a bug that should be a release blocker, but we've been shipping with it for a long time, and so we're reluctant to accept it as a blocker for the upcoming release. We can't waive bugs like these forever, we need a plan. Let's come up with some process/plan what to do with bugs like these. Here's my idea: ---- Accept it as a blocker, because it violates release criteria. Waive it as [hard to fix](https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases), that makes it a blocker for the next release (FN+1). Inform the maintainers that this is accepted as a blocker in 6 months' time. That gives that sufficient time to fix it. If the problem is still not fixed for the next release, waive it as hard to fix again, moving it to FN+2. If the story repeats (still broken in FN+2), propose dropping of the release criterion (or carving some exceptions in it). Because if all of these are true: a) we consider the broken functionality to be release-critical (a blocker) b) the bug has been present for a long time already c) we've waited for 1 more year for a fix and it's still not available d) we're willing to release Fedora every time anyway then it's most probably the right time to stop considering it a release blocker. ---- Thoughts?

kparal added this to the Fedora 45 milestone

2026-03-23 14:05:18 +00:00

kparal added the

points

Priority

High

labels

2026-03-23 14:05:33 +00:00

lruzicka commented

2026-03-23 14:23:02 +00:00

Owner

I believe that we should strive for better quality over time, so we should not lower the criteria. Maybe we should harden them where it makes sense and is possible. The bug you are mentioning is a hot candidate for the reversed process:

If we cannot fix it on time for this release, we could waive it, make it known (common bugs), and block the next release until that is fixed. If it does not get fixed in six months and there is no chance to do so, an authoritative body (Fesco?) should grant an exception for such a bug, either temporarily or eternally and the status quo should be communicated to the public.

The reasoning is -> there might be different bugs that break one or more release criteria. If there is a hard-to-fix bug that cannot be fixed, some other bugs touching that criteria might still be fixable. If we drop the criteria, we'll also let other bugs pass.

Hmm, that does not sound bad on the first sight. As always, there is a "but". Let's say we will apply this strategy to any hard-to-fix bug that we'll find in the future and we can't fix. In a year, we soften the criteria to make this bug pass. In a long term, the criteria will deteriorate and the quality will drop. I cannot tell how quickly and how much, it probably won't be much in the beginning, but the decline is inevitable. I believe that we should strive for better quality over time, so we should not lower the criteria. Maybe we should harden them where it makes sense and is possible. The bug you are mentioning is a hot candidate for the reversed process: If we cannot fix it on time for this release, we could waive it, make it known (common bugs), and block the next release until that is fixed. If it does not get fixed in six months and there is no chance to do so, an authoritative body (Fesco?) should grant an exception for such a bug, either temporarily or eternally and the status quo should be communicated to the public. The reasoning is -> there might be different bugs that break one or more release criteria. If there is a hard-to-fix bug that cannot be fixed, some other bugs touching that criteria might still be fixable. If we drop the criteria, we'll also let other bugs pass.