Making sense of Bugzilla data

tldr; I have created a project status page for Mozilla developer tools and a library called Buggerall that helps to make pages like this.

Poor Bugzilla. It started life as an innocent bug tracker and has come to be counted on as the source of truth for a collection of significant software development projects, and the workflow tracker of Mozilla’s development process.

As manager of Mozilla’s developer tools group, I was responsible for keeping an eye on how our projects were moving toward completion. It very quickly became apparent to me during the Firefox 4 cycle that getting code through the process was just as important as writing the code in the first place. At the time, “through the process” meant gaining blocker/approval status in addition to getting a slot on the super busy review queues of browser peers and successfully managing the back-and-forth of the review process. There is no query you can run in Bugzilla’s web interface to show you how bugs are doing in this process.

Enter Bugzilla’s REST API. Using this API, you can gather whatever data you need from Bugzilla and munge it any way you want. Even better, you can use this API entirely in client side JavaScript, even cross-domain. For my initial report, which showed where a given bug was in the Firefox development process, I had a bunch of code in the page to gather and format the data.

More recently, I’ve made that code more generic and given it new superpowers. It’s called Buggerall, it’s lightly documented CoffeeScript and it’s available on GitHub.

In my new role as product manager for developer tools, I want to be aware of how things are going with the projects, but at a higher level. I also want to be able to track developer tools work as it relates to Firefox features. To that end, I have created a project status page that builds on Buggerall to give me (and anyone else that’s interested) a view into developer tools work.

Some interesting features of Buggerall:

• run queries easily
• you can serialize the result so that reports (like my status report) can use cached data and load very quickly
• but you don’t have to! queries can be live and cross-domain
• new Timeline object lets you gather a feed of events for the bugs in a query

My status page has an updater script (invoked from an update page in the browser) that runs the queries using Buggerall and then mashes the data down to a simpler format used by the status page. The updater uses a Firefox-specific API for saving files which I found in TiddlyWiki.

The status page is built around project metadata that I set up. This metadata allows me to group together arbitrary collections of bugs, which is very handy. This can be done with meta bugs in Bugzilla, but it takes a lot more work to do so. Also, since this is all in git, it’s easy to collaborate with other people on the metadata.

I’m always interested to hear about other techniques people have for getting useful info out of Bugzilla. The query interface that Bugzilla provides is quite powerful on its own, but the REST API makes it easy to gather any data you need and present it any way you want.