Tag Archives: bugs

How to not get spammed by Bugzilla

Bugmail is a running joke at Mozilla. Nearly everyone I know that works with Bugzilla (especially engineers) complains about the amount of bugmail they get. I too suffered from this problem for years, but with some tweaks to preferences and workflow, this problem can be solved. Here’s how I do it:

E-mail preferences

  • Disable e-mail completely for cc changes and other things that don’t generally matter to you. For me, this includes the keyword field and even the dependency tree.
  • If you follow components, make sure you only get mail for NEW bugs in that component. You can cc yourself explicit to things that you decide to care about. This one has been huge for me. I follow 5 components, and I would get hundreds of additional mail per day if I got mail about every change to them.
  • Set “Automatically add me to the CC list of bugs I am requested to review” and “Automatically add me to the CC list of bugs I change” to “never”. See the workflow section below for more on this.
  • Set-up an e-mail filter to automatically mark your own changes as “read”. I like to get mail for this for better searchability, but there’s no reason it should be something I need to look at when it comes in. You can do this by matching against the “X-Bugzilla-Who” header.
  • If you filed a bug you no longer care about, Mozilla’s Bugzilla now has an “Ignore Bug Mail” field that will make it stop mailing you about it.

Here’s what my full e-mail settings look like:

And here’s my Zimbra filter for changes made by me (I think the “from” header part is probably unnecessary, though):


This section is mostly just an advertisement for the “My Dashboard” feature on Mozilla’s Bugzilla. By default, it shows you your assigned bugs, requested flags, and flags requested of you. Look at it at regular intervals (I try to restrict myself to once in the morning, and once before my EOD), particularly the “flags requested of you” section.

The other important thing is to generally stop caring about a bug unless it’s either assigned to you, or there’s a flag requested of you specifically. This ties in to some of the e-mail pref changes above. Changing my default state from “I must keep track of all bugs I might care about” to “I will keep track of my bugs & my requests, and opt-in to keeping tracking of anything else” is a shift in mindset, but a game changer when it comes to the amount of e-mail (and cognitive load) that Bugzilla generates.

With these changes it takes me less than 15 minutes to go through my bugmail every morning (even on Mondays). I can even ignore it at times, because “My Dashboard” will make sure I don’t miss anything critical. Big thanks to the Bugzilla devs who made some of these new things possible, particularly glob and dkl. Glob also mentioned that even more filtering possibilities are being made possible by bug 990980. The preview he sent me looks infinitely customizable:

Lifecycle of a Release Engineering bug

Like most other engineering groups at Mozilla, Release Engineering uses Bugzilla to track most of the work we do. Our bugs and patches use many of the same flags as a Firefox bug, so it’s no surprise that many people expect our bugs to be like Firefox bugs in other ways. I’ve noticed a few instances of confusion recently, so I’d like to try to clear things up a little bit by talking about what’s different about ours.

In order to understand our bugs, a brief overview of our repositories is required. Unlike Firefox, RelEng hosts its code in a number of different Mercurial repositories. Most of these repositories have (or should have) a “production” branch in addition to the “default” one. Our production systems (Buildbot masters/slaves, AWS management machines, signing servers, etc.) track the production branches of our repositories. This is important for a few reasons:

  • Some patches can depend on other patches in a different repository
  • Some patches need to be deployed at specific times
  • Some systems cannot automatically use new code
  • Every commit has the potential to close the trees

Once a patch has been reviewed it will be landed on the default branch of its repository. At this time the checked-in attachment flag is set to “+”. Unlike Firefox bugs, the bug stays open at this point. Many of our repositories have their own continuous integration tests that watch the default branches and do as much up-front verification as they can. Like mozilla-central, we do our best to stay in a shippable state at all times – so if we have test failures, they get fixed quickly or backed out. Sometime later (usually about once per day), someone will merge all of the pending patches to the production branches and make sure the production systems pick them up. Once this is done, they will update the Maintenance page and add a note like “In production” to all of the bugs that had patches merged. Any new jobs that start after this point will be using all of the new code. In most cases bugs will be left open, and closed by their assignee when appropriate.

I hope this helps the next time you’re confused about the state of some RelEng work!