Gavin's blog

I don’t recall precisely how I first got involved with Mozilla, but a large part of my early contributions was triaging bugs. I stumbled across Bugzilla at some point, and I really enjoyed finding duplicates and trying to figure out the root causes of bugs. I would watch the “bugs filed today” query, and try to triage as many bugs as I could. It was a fun challenge to find duplicates quickly, and memorize common issues (this, and later IRC- and bonsai-watching habits and general Mozilla addiction are what led to the coining of the name “gavinbot“). Later, as I took on more responsibility in other areas (e.g. development and code review), I stopped being as actively involved in Bugzilla triage itself; the bugmail hasn’t stopped, though

Recently Tyler posted about his frustrations with the bug triage effort. He raises some good points, but I think one of his premises is faulty:  I don’t think that focusing on the number of UNCO bugs is useful. We should focus on outcomes, not on driving a number to 0 for the sake of it.

Are we missing bugs that we should have noticed, but failed to? Maybe, but we’re never going to be 100% on top of every bug, and I don’t think the situation here is as dire as “5000 untriaged bugs!” makes it sound – a very large percentage of those are duplicates, or invalid, or minor issues that we shouldn’t be focusing on. Spending contributor time sorting through many of those bugs probably doesn’t have a very good cost/benefit ratio. Important issues still tend to bubble up pretty effectively, in my experience.

Are people being discouraged from reporting problems to us because they get ignored? This is a problem, certainly (though again, I’m not sure about the degree). We should fix this by having better tools for giving feedback (i.e. not Bugzilla), and there are already successful efforts underway to do that (e.g. input.mozilla.com).

It’s important to step back and look at the bigger picture – driving a Bugzilla query of untriaged bugs to 0 should only be a goal insofar as it helps us achieve the primary goal of producing good software. I contend that it probably isn’t the most effective way to contribute to that goal at the moment.

Getting Firefox to support multiple processes is not a small task. To satisfy the goals for going to a multi-process model, we’re going to be making changes to how the front-end Firefox application code interacts with Web page content, since all of those interactions will need to occur via cross-process “messages”.

Felipe has done some great work getting basic e10s browser functionality landed on mozilla-central. He’s added an –enable-e10s-compat build-time switch that both sets the pref that enables putting tabs into separate processes, and then also disables a bunch of code that doesn’t work in that situation. The disabled code includes some pretty major things like “updating the security/location bar UI in response to page navigation”. He’s working on getting those pieces working in bug 666801, and the rest of the currently known work is being tracked in bug fxe10s.

As we continue to identify pieces of code that need Electrolysis-related changes (using both dynamic analysis and static analysis – progress is being made on both of those fronts!), we’ll be adding them to that tracking bug, and poking people to get involved in fixing them. Now that –enable-e10s-compat has landed on the trunk, anyone should feel free to pick some of those bugs up, and land these fixes on mozilla-central (via fx-team, if desired!). Tim Taubert has a great post about the basics of rewriting code to support e10s, and Firefox reviewers should all be getting into the habit of reviewing e10s fixes (and ensuring that newly added code is e10s friendly!).