Skip to main content

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):

Workflow

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:

This week in Mozilla RelEng – June 13th, 2014 - *double edition*

I spaced and forgot to post this last week, so here's a double edition covering everything so far this month. I'll also be away for the next 3 Fridays, and Kim volunteered to take the reigns in my stead. Now, on with it! Major highlights:

Completed work (resolution is 'FIXED'): In progress work (unresolved and not assigned to nobody):

More on "How far we've come"

After I posted "How far we've come" this morning a few people expressed interest in what our release process looked like before, and what it looks like now. The earliest recorded release process I know of was called the "Unified Release Process". (I presume "unified" comes from unifying the ways different release engineers did things.) As you can see, it's a very lengthy document, with lots of shell commands to tweak/copy/paste. A lot of the things that get run are actually scripts that wrap some parts of the process - so it's not as bad as it could've been. I was around for much of the improvements to this process. Awhile back I wrote a series of blog posts detailing some of them. For those interested, you can find them here:

I haven't gotten around to writing a new one for the most recent version of the release automation, but if you compare our current Checklist to the old Unified Release Process, I'm sure you can get a sense of how much more efficient it is. Basically, we have push-button releases now. Fill in some basic info, push a button, and a release pops out:

How far we've come

When I joined Mozilla's Release Engineering team (Build & Release at the time) back in 2007, the mechanics of shipping a release were a daunting task with zero automation. My earliest memories of doing releases are ones where I get up early, stay late, and spend my entire day on the release. I logged onto at least 8 different machines to run countless commands, sometimes forgetting to start "screen" and losing work due to a dropped network connection. Last night I had a chat with Nick. When we ended the call I realized that the Firefox 30.0 release builds had started mid-call - completely without us. When I checked my e-mail this morning I found that the rest of the release build process had completed without issue or human intervention. It's easy to get bogged down thinking about current problems. Times like this make me realize that sometimes you just need to sit down and recognize how far you've come.

This week in Mozilla RelEng – May 30th, 2014

Major highlights:

Completed work (resolution is 'FIXED'): In progress work (unresolved and not assigned to nobody):

This week in Mozilla RelEng – May 23rd, 2014

Major highlights:

Completed work (resolution is 'FIXED'): In progress work (unresolved and not assigned to nobody):

This week in Mozilla RelEng – May 16th, 2014

Major highlights:

Completed work (resolution is 'FIXED'): In progress work (unresolved and not assigned to nobody):

This week in Mozilla RelEng – May 9th, 2014

This was a quieter week than most. With everybody flying home from Portland on Friday/Saturday, it took some time for most of us to get back into the swing of things. Major highlights:

Completed work (resolution is 'FIXED'): In progress work (unresolved and not assigned to nobody):

Redo - Utilities to retry Python callables

We deal with a lot of flaky things in RelEng. The network can drop. Code can have race conditions. Servers can go offline temporarily. Freak errors can happen (more often than you'd think). One of the ways we've learned to cope with this is to add "retry" behaviour to damn near everything that could fail intermittently. We use it so much that we've got a Python library and command line tool that are used all over the place. Last week I finally got around to packaging and publishing ours, and I'm happy to present: Redo - Utilities to retry Python callables. Redo provides a decorator, context manager, plain old function, and even a command line tool to retry all sorts of things that may break. It's very simple to use, here's some examples from the docs: The plain old function: 


def maybe_raises(foo, bar=1):

    ...

    return 1



def cleanup():

    os.rmtree("/tmp/dirtydir")



ret = retry(maybe_raises, retry_exceptions=(HTTPError,),

            cleanup=cleanup, args=1, kwargs={"bar": 2})
The decorator: 

from redo import retriable



@retriable()

def foo()

    ...



@retriable(attempts=100, sleeptime=10)

def bar():

    ...
The context manager: 

def foo(a, b):

    ...



with retrying(foo, retry_exceptions=(HTTPError,)) as retrying_foo:

    r = retrying_foo(1, 3)
You can grab version 1.0 from PyPI, or find it on Github, where you can send issues or pull requests.

This week in Mozilla RelEng – April 25th, 2014

Major highlights:

Completed work (resolution is 'FIXED'): In progress work (unresolved and not assigned to nobody):