• Once bug X is fixed, tweet joyfully.
• Once bug X is fixed, update some documentation.
• Once bug X is fixed, add a feature to a fuzzer.
• Once bug X is fixed, retest a fuzz testcase that I assumed triggered bug X but might in fact trigger a different bug.
• Once bug X is fixed, add a regression test for bug W.
• Once bug X is fixed, see if it also fixed bug Y.

I could CC myself to the bug, but then I'll get lots of email and might forget my reason for being CCed. I could create a dependency, but that sends everyone else confusing bugspam and gives me notifications that are easy to miss.

The after-fix tool

I created a tool called after-fix to track these bug-dependent tasks for me. I have a large after-fix config file with entries like:

# Make use of new GC APIs in DOM fuzzer bug 661469

I'll see my note the next time I run after-fix after bug 661469 is fixed.

Pruning workarounds

I've also been using after-fix to ensure workarounds don't outlive their purpose:

• Prune fuzz ignore lists as the relevant bugs are fixed.
• Find obsolete skips and fails in Firefox's regression-test manifests.

Fixing security holes without introducing new bugs

• http://bugzil.la/95849
• http://bugzil.la/468562#c12
• http://bugzil.la/firebug+crash
• http://bugzil.la/ALL+flag:in-litmus?

For example, you can view the list of bugs related to topcrashes sorted by how common each crash is. First, load the list of Firefox 3.5.3 topcrashes. Second, use the "collect buglinks" bookmarklet to view a bug list consisting of the bug numbers listed there. Third, click the "#" added by this Greasemonkey script to sort the bugs by their order on the topcrash page.

Hopefully, this script will allow us to avoid duplicating information between Bugzilla and CrashKill wiki pages, and thus reduce the risk of information in both places becoming out of date.

The zero-day vulnerability in Firefox 3.5 was a frequent crash on the front page of a top-500 Russian site, but we didn't find out about it until after we shipped Firefox 3.5.

The reason we found out about these bugs late isn't a lack of non-English beta users. 1.8% of English Firefox users are beta users, and 1.6% of Russian Firefox users are beta users. Arabic beta use is much higher, at 3.5%, perhaps because Firefox 3 was such a large improvement over Firefox 2 for rendering Arabic text.

Instead, the reason may be that people who don't know English can't report bugs easily. They can't even search Bugzilla to find out whether their bug is known. They went out of their way to try betas, but beta-testing alone does not keep major problems from making their way into a release.

How can we enable the rest of the world to participate in reporting bugs, or at least ensure that we find out about the most frequent problems in other languages?

Reports of crash bugs require a variety of skills to turn into useful bugs: knowing common support issues, tactfully interacting with bug reporters, reducing testcases, finding regression ranges, and knowing how to get each bug to the correct developer(s). I don't expect every triager to be a guru at all of these, so my guide incorporates a workflow that should allow triagers with differing skills to work together efficiently.

I'm going to work with the QA team to organize some "crash bug days" on IRC, but I'm interested in feedback before that as well.