19 November 2008

Tis Better to Dup Than to Convolute

Let's talk about bug reporting.

There's something which occurs very often in bug reports by people who mean well. They find a bug, and to avoid making extra work for triagers, they check for a duplicate first. While that's very thoughtful of them, it often ends up getting in the way. So, let's talk about when you should file a duplicate, and when you should not. This is mostly in regard to hardware bugs, since that's where I see this happening the most. Hardware varies so widely, that this becomes a bit of a problem.

Let's say you install Intrepid and discover that no sound is coming out of your sound card. So, you look on Launchpad and find a bug conveniently titled "No sound in Intrepid." "Perfect!" you think and join in. Seeing a workaround suggested with no response from the reporter, you think you'll be helpful and answer the question for the triager…

Stop right there.

Now, consider the following:

  1. Do you have the exact same hardware?
  2. Are you sure you have the exact same bug?

If, after reading all of the information provided on the bug, you can answer "YES!" to both of those questions, look for what we're calling the "Me Too" feature. At the moment, it's the phrase "This bug doesn't affect me" followed by a "Change" link just under where the bug's Importance is listed. Click "Change" and mark that you are affected. It is not necessary (or recommended) to post a comment saying that you are affected. This just clutters the bug reports.

If your answer is "maybe" or "no," file your own bug. If your answer is "I don't know how to answer those questions," read on.

How do you see if you have the exact same hardware? In the case of sound, video, and networking hardware, check the lspci -nv output. The first line of each section tells you what basic model of that hardware you have. The next line lists the subsystem information, or SSID. The SSID has to do with how the hardware was integrated into the motherboard. It is far from unusual for bugs to be introduced at this level. If yours match and are the same revision, you probably have the same hardware. If there is any discrepancy, file your own bug. For webcams, fingerprint readers, and other things that use the USB interface, check the ID listed by lsusb If it seems you have the same hardware, use the Me Too feature and read on.

Double check exactly what the original reporter is experiencing. Read the full version and any responses they've already given. The title is not enough. If you're not seeing the same behavior, assume it's a different bug.

If it turns out to be one bug that affects multiple pieces of hardware we can always mark them as a duplicate later. That's not a problem. That's part of triaging.

But if it turns out that there are 15 different issues being reported in one bug, that is a problem. If we have 2 people saying something fixes it, and one saying it makes it worse, and a few others say they don't have that exact symptom but rather something somewhat different and the fix didn't work for them…that makes the bug very convoluted. We then try to read through the bug and see what's going on, and it's full of conflicting information. How are we supposed to debug then? We have no solid answers.

Something I see in sound bugs a lot is that one person will file a "No Sound" bug or a "Crackly sounds" bug. Everyone with that symptom jumps on that bug, but they don't belong there. There are multiple possible root causes, and many of them are hitting different ones. But they present themselves the same to the user. What we, as triagers, want to see is that these bugs are filed independently. If, after some debugging, we find that a few have the same root cause, we can mark them as duplicates easily. Finding the 1 root cause to 5 separate issues masquerading as one, though? That's not possible, because really there are 5 root causes and thus 5 bugs. Continuing to pretend they are all one bug just clutters the bug report, making it hard to read and hard to understand.

And that is why I say, "'Tis Better to Dup Than to Convolute."

No comments: