Blocker Bug FAQ

In other languages: English (en) italiano (it) [edit]

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 freeze exception release tracker bugs for?

The freeze exception trackers list bugs that would not block a release, but which are important enough that a fix would be accepted even during a release freeze (hence 'freeze exception'). 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 freeze exception bugs, as there is for blockers: see the QA:SOP_freeze_exception_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

In general, exceptional or unusual cases are unlikely to be considered release blockers, even if the relevant release criterion is not carefully phrased to indicate this. For instance, although there is a release criterion that states "All release-blocking images must boot in their supported configurations.", this criterion is not considered to be violated if a release blocking image fails to boot in some very particular hardware configuration but, in the general case, works fine. The intent of the criterion is that none of the release-blocking images must be so badly built or contain some bug of such showstopping severity that the image simply fails to boot in circumstances where it would usually be expected to work. The criterion is not intended to indicate that Fedora is somehow committed to ensuring its images boot on absolutely every system.

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.