planetmozilla – Page 3

Walking through early bug triage

February 1, 2013 Liz

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.

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.

Bug history and conversations

February 1, 2013 Liz

David Baron wrote an interesting post recently, Moving bug history out of the primary display of a bug report. I have noticed this problem in Bugzilla, that even if a bug is “ready to be fixed” or has patches submitted it is necessary to read through 5, 10, or 50 comments to understand what is supposed to happen next (if anything). dbaron proposes that the main page of a bug report should show its current state. What is true about it? And what is to be done next? This would be obviously awesome for some bugs, but not for others for which there isn’t a clear state of truth. My first instinct is to question dbaron’s idea, as there might be bugs for which the conversation is the most important aspect.

For example Bug 130835 – Make Bugzilla’s index.cgi (home page) useful for logged-in users has over 150 comments, stretching back 10 years. Here the problem may actually be that the bug (or enhancement request) was not well defined in scope, so had no clear end. It might be worth untangling the useful ends of these 150 comments to close this bug, and open several new and more specific ones for which “current state” *could* be summarized as dbaron suggests.

But what about a bug like Bug 83192184 – Make the plugin click-to-play UI look less like ‘plugin broken/crashed’ UI , where there is a useful active conversation? In that case trying to synthesize the conversation at every step of the way, each time someone comments, is probably not useful.

So in some cases there is clear “current state” or content, as there is on a Wikipedia page, but in some, the conversation is the content. I don’t want to have (or read) conversations in a Bugzilla equivalent of Wikipedia talk pages and am not sure that would be an improvement on the current state of Bugzilla comments. For bugs with a long history, especially ones which have mutated significantly since their beginning, the “current state” field might be an easy way to untangle the mess.

Thrills, chills, filters, and bugmail

January 17, 2013 Liz

Any bugmail at all is probably way too much bugmail. That means you will need to set up some structures to filter it!

This explanation may be useful for anyone interested in contributing to Mozilla — especially bugmasters, triagers, and developers. Even if you don’t use the same email setup, there’s some good tips.

Byron (aka glob) explained how I could set up my Bugzilla email, or bugmail. Within Bugzilla, in the Email preferences tab, there are a complicated set of checkboxes to control what conditions in Bugzilla trigger your bugmail. Right now, my email notifications are set to fire off email to me whenever anything happens to a bug I may be interested in.

Bugzilla email prefs

I then set up some users to watch, at the bottom of the Email preferences screen. Whenever Matti, Tyler, or Benjamin do anything with a bug, Bugzilla emails me about it. I can also see that Josh is watching my Bugzilla activity. People often refer to this as “stalking” in Bugzilla, without any creepy connotation intended. It is basically TMI about someone else’s bugs (or what bugs they poke at.)

Bugzilla user watching

“If you watch a user, it is as if you are standing in their shoes for the purposes of getting email. Email is sent or not according to your preferences for their relationship to the bug (e.g. Assignee).” The meaning of that takes a while to work out, much like Bilbo Baggins’ famous statement at his eleventy-first birthday party… “I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.”

I have picked two components to watch. Bugs in BMO (bugzilla.mozilla.org) are organized first by Product, such as Firefox, Firefox for Android, Thunderbird, and so on; then by Component, which seems to be a division by who is working on a particular area or project. You can’t pick a Component, or even see it, till you figure out what Product your bug belongs to. Here is a helpful guide from the Mozilla Developer Network with a list of Mozilla Products and their Components, handily all on one page, so it is easily searchable. I have also been using the list of Modules and their owners from the Mozilla.org wiki.

Bugzilla component watching

We don’t even have any bugmail yet, and see how much we have learned about the structure of a giant complicated FLOSS ecosystem! Hurray!!!! *waves pom poms*

Cheerleader cat

At this point, I made some folders in Zimbra inside a general Bugmail folder. While I’m still not sure how I’ll settle on bugmail organization, right now I have separate folders for my watched components and people. Then, in Zimbra preferences,there is a sidebar option for “Filters”.

Bugzilla filters

Create a new filter, then for users you’re watching, filter on header, and set the header name to X-Bugzilla-Watch-Reason. (For other filters, check the full headers and see what X-Bugzilla header info will work best.)

Bugzilla x headers

Since the X-Bugzilla-Watch-Reason filter contains the person’s email, if they change their own bugzilla email address, my filter will break.

Bugzilla user watching

Onward to Thunderbird, which I have set up with IMAP to check my Zimbra account.

Right-click (or command-click for a mac) on your account name in the Thunderbird sidebar, and choose “Subscribe”. This shows you the folders on your IMAP-connected account. Expand the folders and check the tickybox next to the new folders you just created in Zimbra (or whatever else you use). This will create a copy of that folder in Thunderbird.

Bugzilla thunderbird subscribe

One more step. In the Thunderbird sidebar, right-click one of the new folders that was just copied over from your IMAP account. Choose “Properties”. Then check the tickybox labelled “When getting new messages for this account, always check this folder.”

Now your bugmail will nicely filter itself — in both email clients.

That was non-obvious enough that I really wanted to document all the steps. Maybe some other new hire at Mozilla will be helped!

If anyone has bugmail tips for me, I would appreciate that!

Bonus points to anyone reading this who notices my PretendOffice filter and has a good laugh.