No edit summary |
(update a bit, including for NTH and blocker process pages) |
||
| Line 1: | Line 1: | ||
{{autolang|base=yes}} | {{autolang|base=yes}} | ||
== 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? == | == What types of bugs are generally considered release blockers? == | ||
| Line 6: | Line 9: | ||
== Why aren't sound or audio bugs considered blocker bugs? == | == Why aren't sound or audio bugs considered blocker bugs? == | ||
Sound issues have a very high barrier to being release blockers, because they can be fixed well with an update. | Sound issues have a very high barrier to being release blockers, because they 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? == | == 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. | 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 | == What are the ''accepted'' release tracker bugs for? == | ||
The '' | 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? == | == Is there a list of all the blocker bugs for a release? == | ||
Revision as of 15:44, 19 October 2010
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 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 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