Category: Bugzilla

Categories
Bugzilla Gmail

Using Gmail filters to identify important Bugzilla mail in 2014

Many email filtering systems are designed to siphon each email into a single destination folder. Usually you have a list of rules which get applied in order, and as soon as one matches an email the matching process ends.

Gmail’s filtering system is different; it’s designed to add any number of labels to each email, and the rules don’t get applied in any particular order. Sometimes it’s really useful to be able to apply multiple labels to an email, but if you just want to apply one in a fashion that emulates folders, it can be tricky.

So here’s a non-trivial example of how I filter bugmail into two “folders”. The first “folder” contains high-priority bugmail.

  • Review/feedback/needinfo notifications.
  • Comments in bugs that I filed or am assigned to or am CC’d to.
  • Comment in secure bugs.
  • Comments in bugs in the DMD and about:memory components.

For the high priority bugmail, on Gmail’s “Create a Filter” screen, in the “From:” field I put:

bugzilla-daemon@mozilla.org

and in the “Has the words:” field I put:

“you are the assignee” OR “you reported” OR “you are on the CC list” OR subject:”granted:” OR subject:”requested:” OR subject:”canceled:” OR subject:”Secure bug” OR “Product/Component: Core :: DMD” OR “Product/Component: Toolkit :: about:memory” OR “Your Outstanding Requests”

For the low priority bugmail, on Gmail’s “Create a Filter” screen, in the “From:” field put:

bugzilla-daemon@mozilla.org

and in the “Doesn’t have:” field put:

(“you are the assignee” OR “you reported” OR “you are on the CC list” OR subject:”granted:” OR subject:”requested:” OR subject:”canceled:” OR subject:”Secure bug” OR “Product/Component: Core :: DMD” OR “Product/Component: Toolkit :: about:memory” OR “Your Outstanding Requests”)

(I’m not certain if the parentheses are needed here. It’s otherwise identical to the contents in the previous case.)

I’ve modified them a few times and they work very well for me. Everyone else will have different needs, but this might be a useful starting point.

This is just one way to do it. See here for an alternative way. (Update: Byron Jones pointed out that my approach assumes that the wording used in email bodies won’t change, and so the alternative is more robust.)

Finally, if you’re wondering about the “in 2014” in the title of this post, it’s because I wrote a very similar post four years ago, and my filters have evolved slightly since then.

Categories
Bugzilla Gmail

Gmail and Bugzilla: an update

I recently wrote about Gmail’s threading not handling Bugzilla emails nicely.  Thanks to a patch from Byron Jones, bugzilla.mozilla.org now lets you set an option so that Gmail’s threading will work nicely with Bugzilla.  Just go to “User Preferences”, and in the “General Preferences” tab, enable “Make email subjects compatible with Gmail’s threading.”  Thanks, Byron!

Categories
Bugzilla Gmail

Gmail and Bugzilla

I use Gmail.  I like the way it manages conversations, with one exception.  New bugs reported in Bugzilla cause an email with a title like “New: Fix the bug” to be sent.  All subsequent changes to that bug cause an email with a title like “Fix the bug” to be sent.  So that first email doesn’t get included in the same conversation as the rest of the emails because the subject line has the “New: ” at the start.

This is annoying.  Does anyone know how to fix it, either on the Gmail side or the Bugzilla side?

Categories
Bugzilla Firefox Memory consumption MemShrink

The new leak tracking bugs are live

Yesterday I proposed a new way of tracking leak reports.  It’s now up and running.  Two old tracking bugs have been decommissioned: bug 632234 (which was already resolved) and bug 640452.  Five new bugs have been created:

  • Bug 659855 – (mlk-fx4-beta) [meta] Leaks and quasi-leaks reported against Firefox 4 betas
  • Bug 659856 – (mlk-fx4) [meta] Leaks and quasi-leaks reported against Firefox 4
  • Bug 659857 – (mlk-fx5) [meta] Leaks and quasi-leaks reported against Firefox 5
  • Bug 659858 – (mlk-fx6) [meta] Leaks and quasi-leaks reported against Firefox 6
  • Bug 659860 – (mlk-fx7) [meta] Leaks and quasi-leaks reported against Firefox 7

Please CC yourself if you are interested.  Apologies for any bugspam you received as a result of these changes.  Hopefully this new tracking system will work well.

 

 

Categories
Bugzilla Firefox Memory consumption MemShrink

A new way of tracking leak reports

We get lots of leak reports from users.  There is a spectrum of quality.

  • Some are hopelessly vague and will never lead to anything useful. (“After browsing for several hours, Firefox is using 100s of MBs of memory.  This is unacceptable;  please fix.”)  Bug 643177 is an example.
  • Some are very precise.  This makes them easy to reproduce, likely to be fixed quickly, and easy to re-confirm if other leaks are fixed in the interim.  (“I managed to reduce the problem down to the attached 10 line HTML file, it causes my machine to run out of memory within 10 seconds of loading.”) Bug 654106 is a good example.
  • Most are somewhere between these two extremes.

Because many of the reports aren’t great, it can be hard to tell if the problem is still present some time later. A single leak may be reported N times, then fixed, and N-1 reports stay open.  In short, leak reports get stale.  (This is true of many bug reports, but I think leak reports are more prone to staleness than most.)

How bugs are currently tracked

There is a keyword, ‘mlk’, which is added to almost all leak reports.  There are over 600 open bugs with that keyword, going back over 10 years.  So it’s not much use.

In the lead-up to Firefox 4, I used bug 632234 (which I’ll henceforth call “mlk-fx4-old”) to track potentially blocking leaks.  It worked well.

After that, I created bug 640452 (which I’ll henceforth call “mlk-fx5+”), with which I’ve been tracking leaks in the lead-up to Firefox 5 and later versions.  I carried over unresolved bugs from mlk-fx4-old.  mlk-fx5+ is starting to fill up feel stale.  Basically, I can see it suffering the same problems as the ‘mlk’ keyword before too long.

So I’m thinking about changing how these are tracked.  The basic idea is to use keep using the ‘mlk’ keyword for all leak reports, and then have one leak-tracking bug for each version of Firefox, so it’s clear which version each report applies to.

Steps needed to start this

Add the ‘mlk’ keyword to all mlk-fx4-old and mlk-fx5+ bugs that lack it.

Open new tracking bugs: mlk-fx4-beta, mlk-fx4, mlk-fx5, mlk-fx6.  (The Firefox 4 beta period was long enough, and there were enough leak reports filed against beta versions, that separating mlk-fx4-beta and mlk-fx4 seems worthwhile.)  Make each mlk-fxN depend on mlk-fx(N-1).

For all the existing bugs tracked by mlk-fx4-old and mlk-fx5+, add them to the appropriate new tracking bug.  With one exception: for hopelessly vague ones, just mark them as duplicates of mlk-fxN, with an explanatory message (“we’re not ignoring leaks, look at all these ones we’re tracking!  but your report doesn’t tell us anything we don’t already know, sorry”).

Close mlk-fx5+.

Steps needed to maintain this in the future

When Firefox version N’s cycle starts, open mlk-fxN, and mark it as depending on mlk-fx(N-1).

For all new leak reports, mark it as blocking mlk-fxN, for appropriate N.  Also add the ‘mlk’ keyword.

If someone confirms in a comment that a problem reported in version N is still present in version N+1, mark that bug as also blocking mlk-fx(N+1).

Properties of this system

You can still search for all leak reports, based on the ‘mlk’ keyword.

You can immediately tell roughly how stale a report is likely to be, based on which mlk-fxN tracking bug it blocks.  This is more reliable than the bug number or file date;  for example, we are still getting reports against Firefox 4 even though Firefox 5 (which has fixed a number of leaks) is in beta and Firefox 6 just went to Aurora.  This immediately gives a starting priority for all leak reports:  more recent ones have higher priority because they’re more likely to still be unfixed.

Hopelessly vague reports are resolved immediately by duplicating, so they don’t clog things up.

Tracking bugs shouldn’t get too big and unwieldy, because each Firefox version has a limited lifespan.

Reports against version N still block mlk-fx(N+1), but via one level of indirection.  Reports against version N+2 still block mlk-fx(N+2), but via two levels of indirection, etc.  So the full chain of dependencies is maintained.

We could periodically go through older bugs (eg. 3 releases ago) and ask people to re-confirm, and close out ones that get no response.  But we wouldn’t have to do that.

Am I crazy?

Is this bureaucratic overkill?  I don’t think so.  It’ll take some work, but I’m happy to do that.  It’ll only take an hour or two to set up, and then it won’t be much harder to maintain than what I’m currently doing with the mlk-fx5+ bug.  (I also have plans for writing instructions to help users file better leak reports.)  And it’ll allow us to proceed much more usefully with the lists of leak reports that we have.

But I’m interested to hear if you disagree, or have any ideas for improving it.  Thanks!

Categories
Bugzilla Gmail

Using Gmail filters to identify important Bugzilla mail

Like most Mozilla developers, I get a lot of bugmail. Maybe 10% of that is important, e.g. bugs I filed, bugs I have to review patches for, etc. The other 90% of that is stuff I have a passing interest in.

I have a couple of Gmail filters that I use to separate these two streams of email.  They’re non-obvious, so I promised Paul Biggar that I would blog about these so that he and others could do the same thing.

To catch interesting bugmail, on Gmail’s “Create a Filter” screen, in the “From:” field put:

bugzilla-daemon@mozilla.org

and in the “Has the words:” field put:

"review?(nnethercote" OR "you are the assignee" OR "you reported" OR "you are on the CC list" OR subject:"review granted" OR subject:"review requested" OR subject:"review canceled" OR subject:"feedback requested" OR subject:"feedback granted" OR subject:"feedback canceled"

To catch less interesting bugmail, on Gmail’s “Create a Filter” screen, in the “From:” field put:

bugzilla-daemon@mozilla.org

and in the “Doesn’t have:” field put:

("you are the assignee" OR "you reported" OR "you are on the CC list" OR subject:"review granted" OR subject:"review requested" OR subject:"review canceled" OR subject:"feedback requested" OR subject:"feedback granted" OR subject:"feedback canceled")

I’ve modified them a few times and they work very well for me.  It’s possible there are some cases that they miscategorize but I haven’t seen that happen for a long time.

Update: In the first “Has the words:” field, you’ll obviously need to change nnethercote to something else.