Difference between revisions of "Bug Lists"
(Added bug Table.)
|Line 14:||Line 14:|
Revision as of 17:46, 15 August 2018
|The Audacity Team track bugs and agreed enhancement issues on our Bugzilla. This page is a list of useful Bugzilla links for Developer/Quality Assurance use.
- Table of issues awaiting fix or review by Priority and Bug Type (also available from the Audacity icon on Bugzilla)
- Latest alpha development builds of Audacity
- Ask for a Bugzilla account (for experienced C++ developers or seasoned bug watchers who want to actively fix or test bugs)
- How to submit patches to our feedback address or developers' mailing list
- audacity-devel developers' mailing list information
|If you go to our bugzilla, clicking on the Audacity Icon at top left takes you to a summary table of open bugs. Clicking on the numbers in that table takes you to those bugs.|
|Audacity has some conventions and thinking of its own on Using Bugzilla.|
Bugzilla and The Bug Table
Latest Changes for:
- All open issues that have Patches attached, that are agreed on and ready for developer review ("patch_ready")
- Manual bugs (issues with the written documentation, not infrastructure or coding issues about serving it) - Note: links to MediaWiki:Sidebar, ToDo, Welcome For Editors and Help:Translating are NOT bugs.
Bugs by Priority
|Open Bugs||Awaiting Developer Fix|
|PX||P0/P1||P0 bugs are bugs so bad they seriously impede development. Preventing recording working, or disabling mouse drags or more prosaically a build breaker would be P0. P0's affect the development team and impede testing by the QA team.|
|P0 to P2||P2 only||P1 bugs prevent a new release. These will include most reproducible crashes, most things that cause data loss and most regressions. P1's would affect large numbers of users, if released.|
|P1 to P3||P3 only||P2 bugs still open when the release process starts, can be fixed or not at the discretion of the Release Manager. Unfixed bugs must be release noted.|
|P1 to P4||P4 only||P3 bugs are lower severity bugs which must still be release noted.|
|All Open Bugs||P5 only||P4 and P5 bugs are not release noted. Many of these may be "enhancement issues".|
Assessing bug priority to maintain Quality Requirement
From the start of the 2.0 series, Audacity removed the former distinction between "stable" and "beta" releases in favor of single series of high-quality releases suitable for all users.
Accordingly, the former meaning of a P2 bug as one that "blocks a stable but not a beta release" was discarded. Bugs that would previously have been rated as P2 are now P1. Our Quality Requirement for single releases is as follows.
- Never less good overall than the standard set by 2.0.0 - only trivial regressions are likely to be tolerated in a release.
- Not necessarily laden with new or improved features - in a few releases the main focus may be on housekeeping and bug-fixing, while in most there will be a balance between features and fixes. Major new features will be isolated in plug-ins, and not included in a release until any major shortcomings have been ironed out.
- Not necessarily "fully stable" - perceived stability, like ratings of bugs, is not an exact science. We want to release more regularly than was the case during the 1.3 Beta series, so it is possible that some crash bugs could be demoted from P1 release blocker status if their impact is minor, or if they only occur in rare or non-reproducible scenarios. Driver or operating system incompatibilities beyond our control will normally be "WONTFIX" P3 release-noted.
Workflow when resolving bugs
- When a bug has a fix committed by a developer, the developer should move the bug status to DEVEL - FIX MADE. This means the bug is still OPEN. Then QA should test it, ideally on all three platforms. If QA are happy with the result, they move the bug status to RESOLVED - FIXED. That means the bug is closed. It will not be visible in searches except when searching for Fixed.
- It is suggested the only case where a developer should change bug status to RESOLVED - FIXED should be for bugs P3 and below where a logic error was to blame which does not appear to have possible platform or machine dependencies, AND where this fix has been committed.
If you plan to use our bugtracker you may want to read about the advantages and hazards of bugtracking, along with a bit more terminology.
Tracking "Residual" bugs after a fix can be tricky, but I think that the guideline should be:
- If the residual is part of the original bug description, then it should initially be treated as the same bug (subject to "3" and "4")
- If the residual is due to an incomplete fix of the code that causes the described bug, then it should initially be treated as the same bug (subject to "3" and "4")
- If the description of the residual differs from the original bug description, then it should be treated as a new bug.
- If the residual is due to an error in code that is unrelated to the original bug, then it should be treated as a new bug, even if the symptoms have similarities.
Item 4 is likely to be difficult to determine for non-developers, but the developer that fixes the bug will normally be able to advise. In some cases, "4" may not initially be apparent to the developer, but if it becomes apparent at a later date, the residual may be migrated to a new bug.
If there is doubt whether a "residual" is part of the original bug or not, it should be discussed on the QA list in the first instance. If it boils down to a question of code, then it may be migrated to the devel list.
This approach helps avoid long, meandering bug threads which can otherwise hinder fixes.
- As a rider, if we do choose to include a residual with new steps in the same bug, use
*** STEPS UPDATED ***
In the bug comments. This saves people new to the bug reading all the way back to the start and it makes it clear the bug is open for a residual.
- Fix made by developer, not yet resolved by QA
- Moonphase or Heisenbug
- Enhancement Requests
- Platform Specific
- All awaiting fix or review by developer
Not strictly bug lists...
- Bug Type and Priority. This is showing open bugs. It is possibly the best table for getting an overview of the kinds of live bugs we have.
- Bugs and Issues. This pair of tables splits the actual real bugs from issues (enhancements, summary, review items). We also have this table for closed bugs.
- Status and Priority. This is showing both open and closed bugs. It shows, for example, that we tend to close a higher proportion of high priority bugs than lower priority bugs.
- Status and Bug Type. This is showing open and closed bugs. It shows, for example, that summary issues tend to stay open.