Bug Triage: In search of a bug life

This week’s assignment is a little different. Perhaps, a bit more challenging as well. First order of business is to learn about the business. So, the instructor assigned us some readings.

Recce

According to Schneeman, maintainers spend most of their time figuring out the exact scenario that causes the bug. Replicating the bug takes most of the time in the life of a bug. Much like a patient walking into the hospital, meta information is necessary to attempt to solve a problem. This process of gathering relevant information that is not self-reported and categorizing the issues into identifiable segments is called triaging. Until a bug can be reproduced, we need to gather more and more information.

Separation of Dev and Triager

In middle to large scale FOSS projects, the bug triaging and fixing is usually done by two separate entities. Why? This ascertains that the developer spends time actually thinking about the bug rather than worrying about duplicates, courteous acknowledgments, priority detection and categorization. A non-specific bug should not even reach the developer’s workflow according to FedoraPeople.

Nous commenceons la recherche

Armed with this knowledge, we begin the bug search at the instructor’s suggested location – bugs.launchpad.net . Following the instructiions, I searched through all the bugs and tried to sort them with the NEW label on top. Alas. I was accosted with this cryptic error message.

So, I manually sifted through the list of bugs with all different types of severity and triage status. We are looking for one that is interesting and has an Undecided status. In fact, it should be such that it is easy to replicate.

Found a Moth instead of a Butterfly

While searching, I came across something peculiar. This particular bug was asking the Makefile to be removed since the package has to be built using manual methods anyway. How does one triage this? Well, I dug into the Ubuntu bug triaging guide and quickly identified that this was a feature request. However, there are two types of feature requests – small and well-defined, and abstract. Here’s the rub. The change, per se, is small – just deleting a file. But, this particular suggestion seemed radical. So, I decied to go with the second category. Ubuntu provides a default canned reply to such requests and I simply copied it onto the request. Afterwards, I marked it as Invalid, per the insructions.

Newbie

Within a few minutes of the triage, the original reporter retorted against my classification of invalidation. The bug filer, respectfully, disagreed with my judgment and said that it was not the Ubuntu bug tracker.

In fact, further research revealed that since the feature was specifically to remove a single file, it would have to be forwarded to the upstream package. Now, the bug is already sitting on the upstream. I, therefore, had to label it as Confrimed or Opinion since the it’s an opinion from a user. I decided on the latter and crossed my fingers in hope that this time I do not get exposed.