User:Tyler/BMOsurvival
Contents
BMO Survival Guide
PART 1
How Bugs on Bugzilla are Born, Live, and Die
Welcome to Bugzilla
Bugzilla.mozilla.org (BMO), is a scary place to live. However, with a short orientation (which you are reading), it can be a fun, rewarding, and productive environment. The Mozilla project, which uses the BMO database, would love to have your help. So don't be afraid, but come on it, read the manual, and get started.
The Structure of this Document
This document is designed to help those who need an easy-to-read reference to BMO, and don't want to have to dig through search engine results to get them. There are three pages in this document, each with a specific subject.
Page 1: How Bugs on Bugzilla are Born, Live, and Die
Page 2: Bug Reports, from Top to Bottom
Page 3: Advanced BMO Details and FAQs
Feel free to read from the beginning to the end, from the end to the beginning, or jump right in to where you need to go. When you are done, and if you need more information, Part 3 has an extensive list of links that will give you access to many different resources.
The Heart of Working on BMO
Bugzilla is the heart of the Mozilla project, every Mozilla product tracks its software defects and enhancements in BMO. There is nothing in the project quite as central or quite as important as BMO. For that reason, there are some basic rules (found Here) that have grown up around interactions in Bugzilla, but the entire thing can be summed up in one simple rule:
- Treat People On Bugzilla the Way You Want To Be Treated
The people on the Mozilla project are a friendly, fun-loving bunch for the most part, and will be happy to have your help if you can follow that one rule.
What BMO Is and Is Not
There are two simple things to make clear about BMO. It is an active database that is used by the developers of the Mozilla project, and is not a support forum. While we would love to help you with a support issue, you should use the Mozilla Support Site to get those questions answered. Otherwise, keep reading.
How BMO Works
BMO works very simply. A bug in a Mozilla product is found and reported by someone (often a volunteer). The bug is categorized, triaged, and may be eventually fixed by a patch to the Mozilla source code.
The Life of a Bug
The life of a bug looks like this:
- Reported
- Triaged
- Confirmed/Worksforme/Duplicate/Incomplete/Invalid
- Assigned (Work in progress)
- Fixed (patch in checked in the tree)
- Verified
Stages of a Bug's Life
UNCONFIRMED
Most bugs start out as UNCONFIRMED.
The name UNCONFIRMED (or UNCO) means that no one with CANCONFIRM privileges has been able to reproduce your problem and prove that it is really a problem with the Mozilla product. External applications, such as extensions, anti-virus, etc. often cause issues that look like a bug in a Mozilla application, when it is not.
NEW
YEAH! Your bug was confirmed by a Triage or QA member, and it was proven to be a Mozilla problem. Now it is confirmed and marked NEW.
Don't be disappointed if your bug sits as NEW for a while. There are thousands of bugs, and only so many developers, so it takes time for someone to find it and take the time to fix it. If you can code, try yourself if you want.
Resolved
Resolved is a whole family of resolutions.
Resolved INVALID
If your bug is marked INVALID, it could be for several reasons. It could be a bug, but not in the Mozilla product. In that case, report the issue to the vender of the software that is causing the issue. Also, when spam bugs, or nonsense reports are filed, they are usually marked as INVALID.
Resolved INCOMPLETE
If a bug is marked INCOMPLETE, it does not mean the issue is not a bug. It can mean the bug was not well written in the first place, or no further information was provided, and so the bug was closed. Don't feel bad if you forgot your bug, and it gets closed. Even developers forget their own bugs from time to time. Simply go to the bug, read any comments given asking for more information, and provide the requested info. If the bug is a real Mozilla issue, the report will be reopened.
Resolved DUPLICATE
DUPLICATE is for when a triager determines your bug is the same as one already filed. Make sure to read the bug your bug has been marked a duplicate of, and add any more information if necessary. If you disagree with the duping, add a comment on your bug politely saying that.
Resolved WORKSFORME
WORKSFORME (WFM) is for when a triager can not reproduce the issue, and thinks that it is already fixed in a more recent build of a Mozilla product, but can not find what fixed it. If you can reproduce it on a current build, please leave a comment with details.
Assigned
When a bug is marked as assigned, it has been taken by a member of the community, and they are beginning work on creating a patch. This is a good sign for your issue.
Resolved FIXED
FIXED, yes, you did it! You reported a real bug, provided enough information, and someone (maybe you) created a patch for the bug which was then reviewed and checked into (landed on) the tree.
NOTE: Do not use the "FIXED" state if a Triage team member's advice resolves the issue. In that case the proper resolution will be INVALID, DUPLICATE, or WFM; FIXED is only used when a patch landed in the code base to fix a bug.
Reopened
Oh no, this is not a good sign. REOPENED indicates that the patch submitted into the code base either did not fix the issue or caused other bugs. It also can be used to dispute any of the "RESOLVED" bug states.
Verified
Verified is a simple way that someone else can agree with the closing of a bug. Any bug that is resolved, can be verified as that resolution. It is a nice way to clean up bugs.
Special Cases
While most bugs will fit in the nice pattern above, and few special cases exist. The most common is when a bug is fixed by another patch. Although a patch was not checked in for that specific bug, the bug has been fixed by a known patch. In that case, the bug is marked as FIXED, with a note to the bug that fixed it being put in the whiteboard.
