Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Thursday 10 January 2013

Optimizing Bugzilla Usage

I spend a lot of time processing bugmail and looking at bugs. Interacting with bugzilla.mozilla.org is pretty slow, but I think it could be greatly improved, potentially saving me 15 minutes a day or more. Multiplied across our Bugzilla-using engineers and managers, that could be a large return on investment.

Every day (ideally) I read my bugmail using GMail. This is actually pretty fast. However I often need to load a bug's bugzilla page in the browser, either to re-read the context of a bugmail (earlier comments, or the contents of attachments or patches, etc), or to make changes to the bug --- usually add a comment, but sometimes change flags or other fields. I get bugmail on more than 50 bugs a day usually, and given I often scan my bugmail more than once a day, I reckon I might spend up to an hour on this on many days.

The problem is that loading a Bugzilla bug takes me about 5 seconds under the best circumstances and a lot longer for large bugs or busier networks. Also, every time I commit modifications to a bug I have to wait for about that much time for it to be acknowledged (one has to wait to ensure there wasn't a dreaded "mid-air collision").

Pretty much all that wait time is unnecessary and could be avoided with a different client. For example, we could have a Web app that does the following:

  • Tracks which bugs have been modified since I last viewed them
  • Preloads the complete data for those bugs
  • Lets me instantly move from one bug to the next
  • When displaying an updated bug, scrolls automatically to the first update that I haven't already seen
  • Lets me make changes in situ
  • When committing changes, instantly move to the next bug
  • If there's a mid-air collision, alert me even if I happen to be looking at some other bug at the time
  • Try to avoid mid-air collisions by receiving notifications of updates by other users while I'm viewing the bug
As far as I know, all of these features except perhaps the very last could be implemented using existing Bugzilla API, without changing the server side.

A client like this could make us a lot more efficient in the way we currently work. We'd probably also use Bugzilla differently and more effectively.

Comments

mozjonathan
I've optimized my bugzilla usage by hacking my addon Thunderbird Conversations: the field that usually serves for the inline reply when viewing a regular conversation turns into a field that allows you to directly comment on the bug, when reading bugmail, directly in Thunderbird. I don't have to load the page at all and I can move directly to the next bug. This feature is present in the released version that's on AMO. The performance hit would probably be pretty bad for you, since the addon slows down the loading of messages, esp. with big conversations, but it's worth a try. I believe with minimal hacking one could probably enable other actions to be performed on the bug directly from within Thunderbird.
glob
> Tracks which bugs have been modified since I last viewed them > Preloads the complete data for those bugs that works well for one person, but once many people start using it, you'll be placing significantly more load on bugzilla, resulting in higher load times for everyone.
johnath
@glob - depending on how our usage patterns look, that could be the right decision. I can well imagine that, for instance, doing that for the top 1000 bugzilla consumers, at a load time cost for occasional users, would be the right trade, no?
glob
@johnath fair point :) the major pain point for improving bugzilla's responsiveness is there's practically zero caching of information between requests, so there'd have to be server-side work to deliver improved load times via client-side pre-loading (along with the infrastructure to back it). i've been working on making the architectural changes required to provide better caching mechanisms within bugzilla, and we're also investigating reverse proxies to deliver cached responses to bzapi calls. even though i just don't think roc's suggestions will improve page load times against the current system, i think they are excellent suggestions from a ux point of view.
Robert
That's a good point glob. However, if we introduced a specialized Bugzilla API of the form "list changes and comments since time for bug N", then this hypothetical client could do very aggressive local caching and maybe reduce Bugzilla load. I mean, loading the entire contents of a large bug several times (for several changes in a row) can't be good for the servers.
glob
@johnath fair point :) the major pain point for improving bugzilla's responsiveness is there's practically zero caching of information between requests, so there'd have to be server-side work to deliver improved load times via client-side pre-loading (along with the infrastructure to back it). i've been working on making the architectural changes required to provide better caching mechanisms within bugzilla, and we're also investigating reverse proxies to deliver cached responses to bzapi calls. even though i just don't think roc's suggestions will improve page load times against the current system, i think they are excellent suggestions from a ux point of view.
lizzard
Neat idea, kind of a Bugzilla Reader app. It does sound like the caching would need to be improved before it would scale at all for more than a few users. But maybe building a prototype would be interesting.
Evan M
I noticed the Rust guys use multiple frontends to the same bug backend. See "the issue tracker" on this page: https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust It helps they're using a popular shared system, so the frontends can be written by others. For whatever reason Bugzilla-based projects tend to grow custom tracker features, making it ever more unlikely for them to share those features. (At least that's the state of the WebKit tracker.)
Till Schneidereit
A while ago, I wrote a rough prototype of a Firefox addon that integrates Bugzilla with Gmail: When it detects a conversation thread consisting of bugmail, it switches to a view that's filled with information retrieved from the Bugzilla API. Information was cached, so that looking at the same bug a second time would be instantatious. I didn't continue investigating this, but combined with some parsing of the new bugmail, this could potentially display all information about the bug inside Gmail in a fast way and enable replying from the same interface, too. The prototype is here, if anyone's interested in working on this: https://github.com/tschneidereit/gBugzilla
Anonymous
Robert, I posted your blog as an issue for our YellowGrass issue tracker: http://yellowgrass.org/issue/YellowGrass/345
Anonymous
roc: I'm a Mozillian developing a Bugzilla client called BzDeck using BzAPI. The app is still in the early stage but it will exactly satisfy your needs. See you soon in Toronto! https://www.bzdeck.com/about/
Robert
Cool!
Robert
There is a project going on to develop a Bugzilla client like what I have described. https://github.com/ebryn/bugzilla-ember