Difference between revisions of "Bug Lists"
(Some bug status text.)
|Line 60:||Line 60:|
Revision as of 11:40, 3 August 2010
|The Audacity Team track bugs and agreed enhancement issues on our Bugzilla. This page is for those using Bugzilla or who would like an account on it.
- 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 if you are a developer or bug watcher, or want to contribute patches to fix bugs
Tip: For easy access, bookmark any links in these bug lists!
Latest Changes for:
Bugs by Priority
|Open Bugs||Awaiting Developer Fix|
|PX||P1 only||P1 bugs prevent any release, including beta.|
|P1 to P2||P2 only||P2 bugs prevent a stable release.|
|P1 to P3||P3 only||P3 bugs must be release noted.|
|P1 to P4||P4 only||P4 and P5 bugs are not release noted.|
|All Open Bugs||P5 only|
Deciding on bug priority is not an exact science, and some of the natural 'rules' conflict with each other.
- Reproducable crashes and regressions are generally P1.
- Bugs we cannot progress (e.g. because we have no reliable scenario by which a developer can reproduce them, or because they are bugs in a driver over which we have no control) generally have to be P3 or below, since we do not want them to prevent stable releases.
- There will always be bugs on the borderline, and these may move up and down in priority.
Also a P2 bug in a new feature we can turn off will generally be a reason to turn that feature off in stable releases so that we can get a stable release out.
Workflow when resolving bugs
- The current workflow is that when a bug has a fix applied 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 and the fix has been committed, QA 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 this fix has been committed.
- 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.
- 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.