- 1 How does the blocker bug process work?
- 2 What types of bugs are generally considered release blockers?
- 3 Why aren't sound or audio bugs considered blocker bugs?
- 4 Why aren't suspend issues considered blocker bugs?
- 5 I have identified a bug that I believe is a blocker. Is it okay if I just add it?
- 6 What are the accepted release tracker bugs for?
- 7 Is there a list of all the blocker bugs for a release?
- 8 What about hardware and local configuration dependent issues?
- 9 Common cases of conditional blockers
How does the blocker bug process work?
See the QA:SOP_blocker_bug_process page, which defines the full process.
What types of bugs are generally considered release blockers?
Issues that affect the critical path stuff (graphics, installer, network) have a lower barrier because fixing them with updates is much more disrupting.
Why aren't sound or audio bugs considered blocker bugs?
Sound issues have a very high barrier to being release blockers, because they do not affect critical functionality and can be fixed well with an update.
Why aren't suspend issues considered blocker bugs?
In theory they ought to be, because it's very important functionality for laptop users. In practice suspend/resume is such a tricky area of kernel code that at present we could never commit to a release date if we considered suspend/resume issues to be blocker issues.
I have identified a bug that I believe is a blocker. Is it okay if I just add it?
If you have reviewed the blocker criteria for the release and believe your bug meets the criteria, definitely add it. When in doubt add it to the blocker list. Better to add it and have it removed versus never getting a thorough review.
What are the accepted release tracker bugs for?
The accepted trackers list nice to have fixed bugs for a release. This allows maintainers to assign them a higher priority and functions as a list of bugs for which fixes will be taken through the repository freezes that are imposed near release time. There is a formal process for nice to have bugs, as there is for blockers: see the QA:SOP_nth_bug_process page.
Is there a list of all the blocker bugs for a release?
Yes, Tracker Bugs.
What about hardware and local configuration dependent issues?
Many bugs are not universal: they only affect certain hardware or software components, or certain configurations or combinations of hardware and software components. When a bug causes a criterion not to be met in some but not all cases, the teams involved in the release process will make a judgement as to whether the impact of the bug is severe enough to consider the release as a whole not to meet the release criteria. This class of bug is sometimes referred to in discussion as 'conditional blocker(s)'. This judgement will be based on multiple factors:
- The amount of users, overall, the issue is estimated likely to affect
- The ease with which the issue can be worked around by documentable configuration changes
- The difficulty involved in fixing the issue: whether there is a significant chance that attempting to fix the issue could cause more serious problems
Common cases of conditional blockers
Some types of 'conditional blocker' bug (see previous section) come up again and again, and over time, solid precedents for handling them have been established by the blocker review process. Among the most common of these precedents:
Why isn't my graphics card showstopper bug a blocker? I can't boot!
To make blocker status, a failure related to some specific subset of graphics hardware must usually be a showstopper (it is impossible to complete installation or boot to a usable system without some kind of workaround) and affect at least a few different adapters, with an appreciable portion of the user base affected. This test is applied more stringently the earlier in the process we are (so it has to be a really bad bug to count as an Alpha blocker).
Bugs that affect only a single adapter or small group of closely-related adapters are almost never taken as blockers, as we do not have the development resources available to commit to fixing all such bugs in any reasonable timeframe. We would like to be able to block Fedora releases for such bugs, but given the constraints, it is not feasible. There are thousands of graphics adapters in existence with dozens of implementations and variants of each, any one of which can break without any other adapter or variant breaking. Fedora (and indeed the whole F/OSS world) has a handful of developers focused on graphics drivers. We simply cannot promise that we will make every variant of every adapter work for every release, it is impractical to do so.
Fedora does not maintain a blacklist of adapters that are known to be broken and force the use of fallback drivers with such adapters: this approach, used by some more 'consumer-facing' distributions, does provide a measure of convenience for users and a greater impression of reliability on the part of the distribution, but it comes with the cost that maintaining such a blacklist absorbs development resources which could otherwise be directed to fixing bugs, and can itself produce bugs (like a card being left on the blacklist after the associated bug has been fixed, causing a needlessly sub-optimal experience). We feel that such an approach does not accord with the Fedora Foundations.