BMO/How to Use Bugzilla
How to use Bugzilla(.mozilla.org)
This is currently a draft for a Bugzilla Users' Guide specific to bugzilla.mozilla.org users -- bug reporters, people submitting fixes, code reviewers, triagers, release teams, and others. (This guide may be merged eventually into a new Users' Guide for BMO hosted in readthedocs.)
- 1 BMO vs Bugzilla
- 2 How to report a bug
- 3 needinfo flag
- 4 Dashboards
- 5 Bug triage
- 6 Products and components
- 7 Searching bugzilla.mozilla.org
- 8 Preferences
- 9 Bugmail
- 10 Bug tagging
- 11 tracking flags
- 12 APIs (xmlrpc, jsonrpc, jsonp, rest)
- 13 Getting a copy of the database
- 14 Reports
- 15 Whining
- 16 Permissions and groups
BMO vs Bugzilla
What is Bugzilla, what is bmo, and how are they different?
Bugzilla is an open source project that anyone can download and install, run by volunteers.
Bugzilla.mozilla.org, or BMO, is a specific implementation of Bugzilla, with extra extensions and customizations, maintained by Mozilla.
This page, How to Use Bugzilla, is a help page for http://bugzilla.mozilla.org.
The BMO team has its own set of wiki pages useful for developers and other community members who'd like to contribute.
How to report a bug
To report a bug, you will need an account on bugzilla.mozilla.org.
Creating a Bugzilla Account
There are two ways to create an account on bugzilla.mozilla.org.
Create an Account
From the homepage you can click "new account," which will let you create an account directly. You will need a valid email address.
Log in With GitHub
If you have a GitHub account you can use it to log in.
First click "Log in".
Then click the Octocat/GitHub logo.
If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us. If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf. You'll be identified by the email address you use on GitHub.
Three Things Your Bug Should Have
Bug triagers, developers, and QA folks will need to be able to understand and reproduce the bug.
- Give the bug a specific and descriptive summary.
- Describe the exact steps to make the bug happen again.
- Attach a screen shot, a link, or code, if that will help others understand the bug.
If you're new to bugzilla.mozilla.org, reporting a new bug takes you to the Bugzilla Helper form (you can also always find it at https://bugzilla.mozilla.org/enter_bug.cgi?format=guided). The Helper form walks you through three steps in filing a bug.
Step 1 of 3: Choose a product.
If your bug is in a Mozilla product, select it from the list under "None of the above; my bug is in:". It might in Firefox, Firefox for Android, or some other product. Click the one that is your best guess.
Step 2 of 3: Summarize the bug.
Write a short summary of your bug. It should be specific, clear, descriptive, and searchable. Think of it as a title for the bug. There is also a specific option for translation errors.
After you type in your bug summary, click the "Find similar issues" button. You will get a list of bugs that may be similar to yours.
There is good news and bad news here! The bad: there isn't necessarily an easy way to judge if your bug has already been filed. It takes a little bit of reading and thought. The good news is that scanning this list can help you avoid making a duplicate bug, and keep you informed on related issues.
For this list of similar issues, you may be able to tell from one of the summaries that your bug has already been reported by someone else. Or, to look deeper into the similar bugs, click on a bug number in the left-hand column, opening it in a new tab. Maybe you can tell that it's the same as the bug you intended to file. If the bug is still open, you can click "Follow bug" in the rightmost column if you want to be emailed when there are updates to the bug.
If you don't find your bug, you can create a new bug report by clicking "My issue is not listed".
Step 3 of 3: Describe the bug.
Bugzilla Helper gives you three questions to answer.
- "What did you do?" This helps other people to try to recreate your bug.
- "What happened?" where you can explain the bad or buggy behavior.
- "What should have happened?" where you explain the correct or desired behavior.
There are a few other options that may apply to your bug. In particular, if you believe it is a security issue, check the appropriate box.
Once you're used to filing bugs, you can switch to the advanced bug entry form.
There's a detailed guide to making your bug as well formed as possible: the Bug writing guidelines on MDN.
If you have a question about a bug, and you'd like to direct that question to a specific person, you can do that easily with the needinfo flag.
(screenshot of individual bug with needinfo checked and dropdown menu open)
The person you need info from will get bugmail with (look up the X-Bugzilla-header) in the header. This may get a person's attention faster than adding them to the CC list of a bug.
You can see the needinfo flags you have requested of others and the ones requested of you in your Dashboard.
(screenshot of dashboard)
Trying to answer the "What should I do today" question? Go no further than the dashboards.
My Dashboard, or actually your Dashboard, has some nice options for viewing lists of bugs that may be of interest to you.
Products and components
Bugs in bugzilla.mozilla.org are organized into a hierarchy of categories. Products are high level categories such as Firefox, FirefoxOS, Calendar, or Toolkit.
This is the list of products on BMO: https://bugzilla.mozilla.org/describecomponents.cgi
From this product list, you can click on a product name to see a list of the various components it contains.
When you file a new bug, it can be difficult to know exactly where to file it. People who help manage and triage bug reports often move new bugs into a product and component that is a better fit. This helps bring the bug to the attention of developer teams who may be best equipped to fix it.
Product and component are usually referred to with separating colons; Core::WebRTC or Firefox::General.
Incoming bug reports filed by users new to BMO and that are in the product Firefox automatically are directed into the Untriaged component.
Components can be useful for managing bugmail. Using component watching, you can set up bugmail for all bugs in a particular component.
Why do we have so many ways to search bmo, and how do they work?
Quickseach rocks! You should use it.
Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful.
also, pronouns are amazing
bugmail filtering (via x- headers)
too much bugmail? filter!
Want to organize or keep track of bugs? Use tags.
You can tag a bug with something that will help you find it later in a search. Or you may be tagging a bug to bring it to the attention of a person or a team.
There are three ways to tag in BMO: whiteboard field, keywords, and saved search tags.
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.
The whiteboard field is for free tagging. It's used both by teams and by people who want to track bugs they're interested in.
Bugzilla tips: http://bugzillatips.wordpress.com/2010/11/23/tagging/
At the bottom of every page in BMO you will see the option to "Add the named tag ___ to bugs ____". Tags you create here are private to you by default, though you can share them with groups (through the saved search interface).
tracking-firefox-25? Who's doing the tracking? Should I set these flags? When and why?
Tracking flags are used by developers, triagers, QA and the release management teams to keep track of bugs whose fixes are slated to go into a particular product release. Flags of the form tracking-firefox-26 have a ?, +, or - associated.
For example, a search for tracking-firefox-26 and "+" currently shows around 50 bugs.
If you would like to suggest a bug and its fix be considered (by release managers) for a particular release, mark it with that release and a question mark. This might be good to do for a bug that's been fixed in one release channel but needs to be uplifted to another.
APIs (xmlrpc, jsonrpc, jsonp, rest)
I hear you want to integrate with bmo. Where to start, what to do next, and best practices which won't get you blocked.
Getting a copy of the database
Before you point wget at bmo, we can give you a dump of the database. Really.
Here are database copies for 2013 in a temporary location: http://people.mozilla.org/~mhoye/bugzilla/
For when advanced searching isn't advanced enough. . .
BMO can automatically send you buglists. This requires that you have canconfirm.
Permissions and groups
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org.
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive.
Here's how to ask for canconfirm and editbugs permissions on BMO:
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group "everyone". Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.
You can see your groups and permissions here: