Walking through early bug triage

Here is a good example of a bug that went through several stages of triaging:
Scrolling a page up leaves residue in GTK slider
. I would like to walk through what happens in triaging this bug. Blow by blow report!

The bug reporter, Przemek, was new to Bugzilla, so their report was automatically put into the UNCONFIRMED status. The bug summary (the title) was originally “artifacts on scrollbar in seamonkey 2.15” and it was put into the product Seamonkey and component General. (Here is a list of Seamonkey components, if you’re curious.) Przemek attached a screenshot of the problem. At the bottom right corner of the screenshot you can see the scrollbar has some weird stripes on it.

Scrollbar bug screenshot

Matti suggested a possible duplicate bug. That shows us a related problem and which product and component it might belong to. It also can reveal some people who work on this type of issue.

Another commenter, Slim, relatively new to Bugzilla, chimes in to say they have exactly the same issue, in Linux and that it may be a GTK problem. They include the information from about:buildconfig .

A fourth person, Philip, asks if someone who sees the problem (either the reporter or Slim) can try toggling a preference. Slim tries it but it doesn’t fix the issue. He speculates it is related to Bug 297508. Philip uses the NEEDINFO flag to ask Przemek a question (this emails Przemek with particular Bugzilla mail headers). Przemek replies, which
automatically clears the needinfo flag. Philip then decides to move the bug from the product Seamonkey to “Core”. component General to Widget: Gtk. That shows up as General -> Widget:Gtk in the comments.

Cotton Harlequin Bugs

One week later, Karl shows up in Comment 10. If we look at the list of module owners and peers for Mozilla, we can see that he is the owner for Core::Widget:GTK. I figure he was probably was looking at bugs in that area, or reading his bugmail backlog. There are 328 bugs UNCONFIRMED or NEW for Core::Widget:GTK, which you can see if you do an Advanced Search. Anyway, Karl reproduces the bug and moves its status from UNCONFIRMED to NEW. He added the keyword, “regressionwindow-wanted”. The next day he comes back and adds some info about the regression window and removes the “regressionwindow-wanted” keyword. narrows that window even further. He then moves the bug to
Core:: Layout
and adds the keyword “regression”. It is probably out of his hands now. But whose it it in?

There are over 2300 open bugs in Core::Layout, 1809 of them new and not assigned to any particular person. If I look to see how many of them have the keyword “regression” there are only 140, most of them assigned to “nobody”. So if I wanted to fix something in Core, that might be a good place to look for a bug that needs attention.

All the commenters described here were doing bug triage or what I am now calling bugmastering. Five people, two weeks. I think all their efforts and comments were useful in moving the bug along and adding new information to it. It is also instructive (and for me, reassuring) that not everything was “right”, right away. Actually, I think it’s beautiful to see how well everyone communicates, much of the time in Bugzilla.

At this point, if Bugzilla had the READY status implemented, I would call it READY. Not just to signal to developers that it is ready to be worked on, but to signal to other triagers that it may be done and they don’t need to keep looking at it. That is part of why having a clear demarcation point will be useful. Even though there is more than could be done, this is probably enough for someone knowledgeable to take it and work on it. I would consider its “early triage” life to be over and for it to be in the hands of engineering, QA, and rel-eng, who have their own models for triaging internally for their stages of handling the bug.

Now, that doesn’t mean that as your Mozilla Bugmaster, I can blithely ignore all bugs once they are done with early triage. Yet since this is a minor layout bug that does not seem to affect function I think I can let it go and hope that someday it is fixed.

It is possible that we could make some cruft-killer searches, reports, or other views that could pick up this sort of bug 6 months from its first reporting, and do anohter check to see if it still exists. If it’s been cleared up in the meantime, make a comment mark it RESOLVED WORKSFORME. Right now I’m sure some people have figured out good systems to do this, but I think most people stay focused on what’s incoming or what is especially brought to their attention. Re-assessing old bugs, or bugs within a particular time window (6 months to a year old, but not 10 years old) may be a good way for beginning bugmasters to start chipping away at some of the cruft in the system.

Bugzilla quicksearch, or else!

Here is a fabulous tip if you are messing around in bugzilla.mozilla.org and are searching for bugs. As, by now, as a reader of my blog, you should be.

You can search Bugzilla right from the location bar. I cannot quite bring myself to say “Awesome bar” as people do at Mozilla because I’ve said “location bar” for many years, and it feels silly.

First you will need to be logged in to a Bugzilla account!

Right(command)-click in the Search box. Choose “Add a keyword for this Search”.

Pick something short that you will remember, like “b” or “bug”. I added both since they both seem intuitive enough to me that I’ll probably forget choosing one or the other.

Command-L is the keystroke on a Mac to move to the location bar.

So, type Command-L, type bug 831552 and you will be whooshed directly to that bug.

Command-L, bug retina will result in a fairly quick list of around 18 bugs (as of right now.)

Here are a bunch of quicksearch tips for bugzilla.mozilla.org!

Take a look at the tips and see what quicksearch looks at by default. There is lots of useful info there and it is worth going through and trying some of the options and noting which field names might be specially useful.

The Advanced Shortcuts are the best thing about quicksearch for me so far. For example, Command-L, bug UNCO retina returns all the unconfirmed bugs with the keyword “retina”. (About 4, currently). Though keywords aren’t case-sensitive, the Advanced shortcut “Status” search terms are. So you have to type bug UNCO retina, not bug unco retina.

At the moment, quicksearch look in comments and various other bug metadata. After January 24th that will change — comments will be excluded by default from quicksearch. That should make it actually quicksearch instead of kinda_slow_search. Or at least quickersearch. Until then, you can type bug --comments retina and your search about retina-related bugs will be a bit faster.

Here is the “or else” part from the title of this post: If you have been calling yourself “The Bugmaster for Mozilla” for several weeks, and you slowly mouse over to a search box to type something, and you do this in front of some kick ass developer, instead of using quicksearch in the location bar, you will be embarrassed. So take it from me and don’t do that.

cats in hats