my experience with bug triage

I have been always wanting to contribute to Ubuntu since the day I joined Ubuntu India Team. But, other things happening around me always kept me from converting this wish into action. It was this new year that I finally took a resolution to start some solid contribution to the Ubuntu project. The most viable options was to Ubuntu Bugs at Launchpad, which in better terms is the bug tracking system for Ubuntu.

The formal way to help with bugs (not formal as it literally means) is to join the bug squad, the team of ubunteros whose sole motive is to check bugs filed by the users, help the users provide as much information about their problem as possible, assign bugs to related packages, find earlier reports which is very similar or sometimes the same (duplicate bugs), assign status and importance for bugs and finally make it all ready for developers to work on them. This process also filters out reported bugs which are not bugs but user end mistakes, which are rather feature requests (wishlist) or merely misunderstood normal behaviors. In addition, we can also file patches for the bugs if we know how to fix them, which actually reduces a lot of developer time (which is precious).

So, where did I get started? Actually two places, one is Launchpad Bugs for Ubuntu and second is the bug squad team channel #ubuntu-bugs at irc.freenode.net. When I joined the team, the irc channel was both a place to discuss about bugs as well as where the bug announce bot was running, announcing the channel whenever a new bug was filed. Later, the bug announce was moved to #ubuuntu-bugs-announce channel, while #ubuntu-bugs became a complete discussion channel for the bug squad. Then I started reading the docs in the wiki, especially the following,

1. How to Triage
2. Debugging Procedures
3. Standard Responses
4. Bug Importance
5. Bug Status

Apart from reading docs, I started observing how triagers respond to bugs. When I got an idea of the basics, I started triage with some newly filed bugs, easy ones which I could make sense of from the description. All I did was find bugs where I can ask for more information from the reporter. This is the easiest way to start as most filed bugs lack in one information or another, and it’s the primary task of the triager to get as much information from the reporters as possible.

Most people miss out the Ubuntu version they are reporting the bug against, the related package for which the bug is filed and it’s version. These are minimal information required in the bug report. The next important thing is how complete and meaningful is the bug description itself. It is not uncommon for people to be in a tensed mood when they file bugs and their description is quite unclear about their problem. Minimal requirements of a good description are what is their problem and how to reproduce this problem. Some reporters also specify things they tried to fix the problem, and surprisingly sometimes this ends to be round about solution for the problem. Some people take more responsibility of getting into the problem, finding a fix and submitting a patch to the bug as well (which is amazing btw). Now bug triage doesn’t seem to be simple all together, but it offers various levels of participation fitting with one’s level of interest and skills. I know of a few in bug squad who are specialist in dealing with duplicates, which is nothing but a reporter filing a bug which already someone (or even many others) have filed already.

Filing a same bug doesn’t help much, rather what would be welcome is looking at existing bug and adding additional information to it if possible. Similarly, one can also check existing bugs and if the problem can be reproduced at our end we can indeed confirm the bug reported by someone else.A bug also gets confirmed when the triager feels that the bug report enough information for the developer to deal with it. There is no hard and fast rule, but some guidelines on what makes a report complete (which you can find in link 1 above) and is often acquired as a trait by experience.

There is not much for the basic level of bug triage. As I got involved doing these basic things, I started learning more. Sometimes I have done little mistakes, but as I always refer to people in #ubuntu-bugs for doubt, my mistakes got immediately corrected. Am still in the lower levels of bug triage, but learning a lot. One wonderful endeavour regarding bug triage is 5-a-day project started by Daniel Holbach. It is nothing but a team of bug triagers who make sure they at least triage 5 bugs a day. This has really been working and if you would like to see some stats check this one out.  One handy link for every new triager is the Checklist.

So, when can you join us? Anytime anyday and if you are looking for special time to join then Hug Day and Global Bug Jam could be a nice opportunity

if you are in a mailing list

Still I remember the day I joined my first ever mailing list, with a warning from my mentor not to immediately jump into mailing the list. It was followed by 3/4 months of observation period where I just kept reading mails, queries and replies. I was asked to learn how people ask questions, how people answer questions and how you shouldn’t ask/answer a question. It also helped me understand the entire idea about mailing list. I also learned about flaming and when did people landed in the middle of one. The monthly reminders on Net-etiquette where quite useful and kept me reminded on what I shouldn’t do. Still there were certain instances where my butt got burnt a little, but its quite normal.

Of late I got an additional responsibility in the ubuntu-in team, as a moderator for mailing list. Since then I have been seeing the inner world of mailing list, only known to the mail admins, about spams, over-the-limit mails, etc. That’s why I decided to write this post, of what not to do and what to do when you are in a mailing list.

1. Read the mailing list guidelines, otherwise called as netiquettes, and follow them.
2. Try to improve your linguistic skills, so that you can ask better understandable questions and offer clear replies.
3. Observe the mailing list before you take active participation. This helps in knowing the unwritten rules followed within the list community and understand better the common participants in the list.
4. Observe the common participants and pick up a mailing style, while still following the list guidelines such as “do not top post”, “do not over quote”, “crop unwanted text” etc.
5. Most mailing lists are enabled with “reply-to munging”, which means when you press the reply-to option in your mail client it automatically selects the list mail address as the reply-to address. Be careful, especially when you trying to mail the OP offline and do not want the list to know about it
6. Please do not indulge in personal duel. Mailing list is also a community and has people who differ in their way of life, profession, experience, expertise, ideologies etc. If you are not ok with anyone’s idea, just state you do not agree, place your points. If the conversation seems to digress somewhere, please remind silent so your butt is not burnt.
7.  Please answer things which you are very sure of. Try to understand what the conversation or query is actually about before trying to post a reply. Its quite embarrassing to be pointed out that you misunderstood and gave some crap as a reply.
8. Do not repeat points already posted by others. If you want to second on a posted opinion use “+1″ to mark you support the idea.
9. There might be a lot of discussions happening in the list. No one tries to participate in everything, though you might follow them up. Please think twice before venturing into unknown lands.
10. Please stick to the purpose of the list and do not digress. Though many list allow off-topic posting with a “[OT]” tag, that doesn’t mean you can ask anything under the sun.
11. I seriously advice to use a separate mail account for mailing list subscriptions. This is not just to manage the huge amount of mails you get, but to prevent unknowingly sending personal stuffs, forwards and spam mails to the list.
12. Those who send “join me in foobar social networking service” are considered to be the worst type of spammers and the list administrator might resolve to kick such people out from the list. Beware!
13. If the mailing list doesn’t welcome wishes and greeting mails, like “Happy New year!”, please refrain from sending one to the list.
14. Do not talk about food, religion or politics in a mailing list. These are topics where people have their own preferences and are quite strong in them. Indulging so might lead to people’s sentiments getting hurt and you getting flamed at the end.
15. Even when pointing others about their mistakes, please be polite. Do not make fun of other’s innocence or negligence. If you are proved wrong, just accept your mistake and learn from it.
16. New members of the list will be quite enthusiastic (may be they didn’t read a post like this ). Please understand it, give them time and support to learn. Flaming their butt will just create fear and they might leave the list calling it to be unfriendly or egoistic.

Remember, these aren’t rules but just some tips I learnt through the experience of participating in various mailing list for the past few years. Hope it does some help people who are venturing into the new world of Mailing Lists. Good Luck!

(Bash) Copy with Find

Wanted to copy all my EPM .list files to a separate folder so I can do a bit of edit and test with it. Wanted to do it in a true geek mode and hence decided to make use of bash’s find command (Thanks to floyd_n_milan for introducing me to this wonderful command). Since it some time I really used `find`, I had to do a bit of Googling to find I needed. This might be a piece of piss for seasoned Bash’ers but for me it was a chance to revive my detoriating Bash knowledge and as it always happens, I love to post newbie stuffs.

$ find ./myproj/pkgs -name \*.list -exec cp {} epm-list/ \;

This command searches the myproj/pkgs directory (within current directory) and its sub-directories for files ending with .list. Upon each file found, it executes the `cp` command copying the file to the directory epm-list. The {} is replaced by the name of the file found (each time).

Please note the escaping ‘\’ before the ‘*’ in the regular expression and before the trailing ‘;’. If you miss the trailing semicolon or the escaping, bash will complain that the -exec has no options. We need not put `epm-list/{}`, it uses the file name automatically (if we use {} then it tries to put the file in epm-list/<path-where-the-file-is-actually-found> which ends in a path not found error).

GNU Units - for conversion between units

Again Planet Ubuntu has introduced me to a new tool, may be not new for you, which is very useful in day to day life. Its `units`, which helps in the conversion of one unit to another. It can be invoked from the command line (aka terminal), either by passing the input and output units as arguments or using the interactive mode. It supports 2438 units, 71 prefixes and 32 nonlinear units.

When you just call the units, it fires up the interactive mode,

$ units
2438 units, 71 prefixes, 32 nonlinear units

You have: _

Now we have to enter the input unit, that is the unit we want to be converted. Say “1 inch” to be converted to cms. For this “You have:” is “1 inch” and “You want:” is “cm”.

You have: 1 inch
You want: cm
* 2.54
/ 0.39370079

It gives two outputs marked by * and /. The first one (marked by *) is the forward conversion, i.e., inches are represented in cms. The second one (marked by /) is the reverse conversion, i.e., it is the representation of 1 cm in 1 inch.

Let us look at some common conversions which we might me interested in general.

You have: inch
You want: cm
* 2.54
/ 0.39370079
You have: feet
You want: cm
* 30.48
/ 0.032808399
You have: feet
You want: inch
* 12
/ 0.083333333
You have: meter
You want: inch
* 39.370079
/ 0.0254
You have: meter
You want: cm
* 100
/ 0.01
You have: kilometer
You want: inch
* 39370.079
/ 2.54e-05

We have looked at conversion of units for length|height. Now lets see for weight and volume.

You have: kg
You want: lb
* 2.2046226
/ 0.45359237
You have: liter
You want: m^3
* 0.001
/ 1000
You have: gallon
You want: liter
* 3.7854118
/ 0.26417205
You have: gallon
You want: m^3
* 0.0037854118
/ 264.17205

There is one more common conversion left out, degC to degF and vice versa.

You have: degC
You want: degF
* 1.8
/ 0.55555556

These are basic conversions where we compared one unit of input to corresponding output. Now lets looks at different values and the corresponding results. There is an interesting thing to note here.

You have: 5 inch
You want: cm
* 12.7
/ 0.078740157

A inch is 2.54 cm and 0.39370079 cm is one inch. Looking at the current conversion, 5 inches is 5 *2.54 cms= 12.7 cms. But what is the second value “0.078740157″ ? This is nothing but the 1 cm with respect to 5 inches, or how much 1 cm is a part of 5 inches (1/(2.54*5) = 1/12.7 = 0.078740157). It might be a bit confusing at the beginning, but this is useful at times when we want to know the reverse ratio as well.

You have: 8 meter
You want: inch
* 314.96063
/ 0.003175
You have: 400 feet
You want: cm
* 12192
/ 8.2020997e-05
You have: 72 kg
You want: lb
* 158.73283
/ 0.006299894

Now, let us try to convert between units which do not have much relation.

You have: kg
You want: liter
conformability error
1 kg
0.001 m^3
You have: kg
You want: m^3
conformability error
1 kg
1 m^3

Though it shows the conversion, it says conformability error. Lets try again with mutually incompatible units.

You have: liter
You want: ohm
conformability error
0.001 m^3
1 kg m^2 / A^2 s^3

What it does is convert it to common base (m^n) and try to match them. But still, it doesn’t conform to standards conversions.

What if we are not sure of a unit or do not know how to spell them exactly. Just enter the first few letters and press tab, it shows a list of related units.

You have: kg
You want: l
Display all 102 possibilities? (y or n)
You want: li
li              lid             line            lithium
liang           light           linenyarncount  lithuanialitas
liberiadollar   lightminute     link            litre
libra           lightsecond     liquidbarrel
librae          lightyear       lira
libyadinar      ligne           liter

Another interesting feature of this tool is that we can obtain quick definitions of units. For example, if we want to know about ‘tablespoon’ then enter it in the “You have:” option and just press `Enter` without typing anything for “You want:” option. Then you get,

You have: tablespoon
You want:
Definition: ustablespoon = 1|16 uscup = 1.4786765e-05 m^3

Another good example will be definition of ohm and volt.

You have: ohm
You want:
Definition: V/A = 1 kg m^2 / A^2 s^3

You have: volt
You want:
Definition: W/A = 1 kg m^2 / A s^3

Thus, the interactive mode of GNU Units is very useful tool and we can play around with it. When we exactly know what we have and what we want, and just want the answer, the command line mode will be preferable. The basic syntax is,

$ units [options] [from-unit [to-unit]]

For example,

$ units '8 meter' 'inch'
* 314.96063
/ 0.003175

When the same command is invoked without the second ‘to-unit’ option, it just displays the definition of the given unit. For example,

$ units 'feet'
Definition: foot = 12 inch = 0.3048 m

Thus `units` is a versatile tool which converts quantities expressed in various scales to their equivalents in other scales. More information and options can be got from `man units`. The home page provides more information about the tool.

Units is available in Debian and Ubuntu, in the `universe` repository for the latter. So, its all an ‘apt-get install’ away. Thanks to lucas for posting this on the planet. Have fun!