Tips and tricks on how bugzilla works

Here are some basics explained as well as quick tips and tricks on how to use bugzilla. Bugzilla may do some things from time to time that help or hinder, so knowing what they are when they happen can be useful.

Back to Bugsquad main page

Bugzilla basics explained

• Who can add comments
  Anyone can add a comment to a bug in the "Additional Comments" box, so long as they have created a bugzilla account.

• What the reporter can do
  The reporter of a bug can modify any aspect of their own bug (e.g. close it, reopen it, etc.), unless the bug was reassigned to unknown@bugzilla.gnome.org (which means that the reporter didn't first register their email address with bugzilla)

• Automatic changes bugzilla makes to comments

  • The text "bug xxxxxx" (where xxxxxx is the number of some bug report) is transformed to a hyperlink to the appropriate bug report.
  • The text "comment #xxxxxx" (where xxxxxx is the number of a comment within the bug report) is transformed to a hyperlink to the corresponding comment.

  • Any text starting with "http://" in it is transformed into a hyperlink to the listed website.

• Changes that bugzilla automatically does on reports
  When one bug is marked as a duplicate of another, both bugs get an extra comment: The duplicate gets a comment that looks like "This has been marked as a duplicate of bug xxxxxx". The duplicated bug gets a comment that looks like "Bug xxxxxx has been marked as a duplicate of this bug".
  The email address of the reporter of the duplicate (new) bug will be added to the CC email list of the duplicated (older) bug, unless the duplicated bug is in the RESOLVED state. Thus, you should reopen the older bug first and then duplicate the new bug if the old report is in the INVALID or INCOMPLETE state so that the email address will be added.

• Mid-air Collisions
  If you and someone else both try to modify the same bug, the second person to submit their changes will be notified of a "Mid-air collision". You will be given the option to erase the other person's changes and keep your own, or to throw away your changes and revisit the bug. Unless you have an extremely good reason to do so, you should not erase the other person's changes. There are two ways that I handle these. If the first person's comments and changes make mine unnecessary, then I'll just throw my changes away; otherwise, I hit the back button on the browser, hit the reload button (which will update the bug but leave the boxes filled in with my comments), double check to make sure everything is updated correctly, and then submit again.

• Reassigning bugs
  When you change the product for a bug in bugzilla and push the "Save Changes" button, bugzilla will bring up another screen prompting you to change the component, target milestone, and version instead of immediately processing your changes. Look here for an examples of what this screen looks like.

• Bug report history
  The "View Bug Activity" link at the end of each bug report often contains some useful information about the history of the bug and how different fields have changed.

• Bug Buddy's frequently reported list
  To get a bug to appear in Bug Buddy's frequently reported bug list, add the bugbuddy keyword to a bug.

Exploiting Bugzilla in order to increase your productivity

Custom bookmarks

Custom keywords allow you to jump to a known bug ID without having to browse to bugzilla first. A full explanation of their implementation in Mozilla is available at mozilla.org. They are also implemented in Galeon and the Opera web browser but are called nicknames. (If you write a quick HOWTO of how to implement them in your favourite browser I'll post it here.)

Adding queries to page footers

Look in your bugzilla preferences. If you save a query and give it a name, you can make it appear in the page footer for every bugzilla page. Spend a bit of time to save common queries - it saves you time in the long run!

Using the status whiteboard to flag bugs

Bugzilla has a status whiteboard. In general, bugsquad members can add things to this field to make bugs easy to find - a bit like a custom bugzilla keyword.

For example, for bugs that I think may often get duplicates reported I put AES[DUPSINK] in the status whiteboard (sinking the duplicates like little rubber ducks :). Then I can make a query that searches for all bugs with that in the status whiteboard to find them again.

A couple of notes on this though.

1. When you put something in the status whiteboard, always use the form NICK[KEYWORD] where NICK is your IRC nickname or something else that identifies you. That stops multiple people getting confused if they put the same thing in the status whiteboard - a kind of primitive namespacing.
2. Always add to what's already in the status whiteboard, never remove what's already there. Other teams, like the accessibility team, use the status whiteboard for other purposes.

Back to Bugsquad main page