Ubuntu Wiki

Introduction

On Saturday May 3, 2008 Pedro Villavicencio and bugsquadder Iulian Udrea gave a brief class on triaging bugs as a part of Ubuntu Open Week. Pedro is a team lead of the Ubuntu Desktop Bugs team, and Iulian is an experienced triager-turned-Ubuntu MOTU. The following is a brief summary of what they spoke about in format that is a bit easier to read than the original IRC log. It can be a bit easier to absorb than the wiki itself, since it is in narrative form. The transcript has been altered for stylistic/readability/consistency reasons and to utilize the higher technology level of a wiki. Questions have been moved out of chronological order and to the bottom of their respective sections. If you would like, you can see the original IRC Transcript.

About Ubuntu BugSquad

Pedro Villavicencio: The Ubuntu BugSquad is the first point of contact for bugs filed about Ubuntu. We keep track of them, and try to make sure that major bugs do not go unnoticed by developers. This is accomplished with a process called "Triage" which I will talk to you about in a few minutes. Working with the Bug Squad is an excellent way to start helping out and learn a lot about Ubuntu and its infrastructure. You do not need any programming knowledge to join the team. In fact, it is a great way to return something to our lovely Ubuntu project if you cannot program at all. We have several points of contact; a team on LaunchPad-https://launchpad.net/~bugsquad, a mailing list, and two IRC channels #ubuntu-bugs and #ubuntu-bugs-announce. All these points of contact are open and available to any member of the Ubuntu community so feel free to join them anytime.

Bug Triage

Pedro Villavicencio: Bug triage is an essential part of Ubuntu's development and consists of several responsibilities:

• Responding to new bugs as they are filed.
• Ensuring that new bugs have all the necessary information .
• Assigning bugs to the proper package.

  • Brian Murray already talked to you about these things so we hope you'll be filing good quality reports! Most of the bugs we have to deal with are not assigned to the right package, or and moreover not assigned to anything. If you look to this list of new and unpackaged bugs, there are over 1,500 new bugs without a package assigned.

• Confirming bug reports by trying to reproduce them.
• Setting the status of bugs reports.
• Searching for and marking duplicates in the bug tracking system.
  • For this, you might want to look to the Upstream article for instructions on how to do it.
• Sending bugs to their upstream authors, when applicable.
• Cross-referencing bugs from other distributions.
• Expiring old bugs.

All of these activities help the bug get fixed and subsequently making Ubuntu even better. They are also a great place to gain experience triaging bugs. As soon as you have done enough good triage work, you can apply to the Ubuntu Bug Control team which is the one with more rights over the reports. The requirements for joining the team can be found here. This will allow you to:

• Manage bug importance.
• See private bug reports.
• Set special bug statuses (Triaged, Won't Fix).

Sourcercito: QUESTION: how long does it take to be able to join the ubuntu-bugcontrol team?

Pedro Villavicencio:It depends on how much work you been doing, the whole process can be as short as few weeks for a new triager to start doing good work and apply to the team and get the membership.

Bug Status

Pedro Villavicencio: We currently have 9 status, they are: New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Fix Committed, Fix Released and Won't Fix. New status means that no one has triaged or confirmed the report. The Incomplete status means that the bug is missing some information. For example, it could be missing the steps that trigger the unwanted behavior. A Confirmed status is almost self explanatory; someone other than the reporter has experienced the same bug. I guess that Brian told you this, but just in case: Please do not confirm your own reports. The Triaged state is set by a member of the Ubuntu Bug Control team when they think that the bug has enough information for a developer to start working on fixing the issue. If a bug was marked as Triaged and a Developer has started working on fixing the bug, that report needs to be marked as In Progress. Please use "In Progress" only if a developer is working on a bug. I've encountered some bugs marked as In Progress because the reporter is collecting more info because a triager asked they to do so, which is incorrect. Those bugs are considered Incomplete, not In Progress. If a developer has committed a fix to a bzr branch or to another repository the report needs to be marked as Fix Committed, and when the fix is released (meaning available on a official Ubuntu repository) the status of that bug report needs to be changed to Fix Released. If you have any doubt or want to know more about status, you can read more here. Does anybody has a question regarding bug status?

Iulian Udrea: It seems that you missed the 'Invalid' status. This status should be used when the bug report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter. Be careful when you set this status, when a bug has the invalid status it will no longer show up in default searches.

Monika|K: QUESTION: Can all of the status only be set by the Bug Team? Or can some status be set by other people and only some are reserved to the Bug Team?

Iulian Udrea:All statuses can be set by everyone, except Triage and Won't Fix. You have to be a member of the Ubuntu Bug Control to set those two statuses.

Bug Importance

Pedro Villavicencio:As I said earlier, one of the nice privileges you're going to have if you join to the BugControl team is set bug importance. We currently have 6 importance levels; Undecided, Wishlist, Low, Medium, High, and Critical. Until you are a member of UbuntuBugControl you will not have the permissions necessary to set importance, however you can always ask on #ubuntu-bugs for someone to set an importance for you. Undecided is the default for new bugs. It means that there's not sufficient information to determine the importance, or a member of UbuntuBugControl hasn't had the time to set the importance yet. A Wishlist is a request to add a new feature to the programs available on Ubuntu, or to have a new program added to the Ubuntu repositories. When a wishlist request is too complex, it should be written as a feature specification. Also, if you have some ideas that you'd like to see included on Ubuntu you can use the Ubuntu Brainstorm website where you can upload and vote for ideas. The ubuntu developers discuss the better ones at the Ubuntu Developer Summit.

Iulian Udrea: We currently have ~8000 ideas reported on the brainstorm website.

Pedro Villavicencio:Yep, so feel free to add yours or vote for one that you'd like to have in our next version.

Iulian Udrea: Every day we get at least 5-10 ideas. Ok, so let's get back to the Importance of a bug. The Low importance are the bugs which affect functionality to a very small extent. They can be easily worked around, or are the bugs that affect unusual configurations or uncommon hardware. It is a bug that has a moderate impact on a non-core application. Most bugs are of medium importance. For example, it has a moderate impact on a core application or, it's a bug that has a severe impact on a non-core application. You can set this importance if you have a problem with a non-essential hardware component (network card, webcam, sound card, printer, etc). High importance bugs are ones that have a severe impact on a small portion of Ubuntu users or a moderate impact on a large portion of Ubuntu users. It makes a default Ubuntu installation generally unusable. For example, a system fails to boot or X fails to start on a certain make and model of computer. The Critical importance is pretty much self-explanatory. Only set this importance if a bug has a SEVERE impact on a large portion of Ubuntu users.

nosrednaekim: QUESTION: what about the bug status "wishlist"?

Iulian Udrea: There is no such status, that is an importance. You set that importance if it's a feature request. Refer above for more information.

Hug Days

Pedro Villavicencio: If you want to work with the BugSquad, we organize frequent "BugDays," also known as Hug Days (triage a bug and get a hug). The idea of a hug day is to work together with the BugSquad and project maintainers to focus our collective effort on a specific task. Weekly we organize two hug days, Tuesdays and Thursdays. Tuesdays are more general hug days, focused - for example - on the bugs without a package. The Thursday ones are focused on desktop related task like compiz, firefox and GNOME applications. If you want to join us at Hug Days just come to #ubuntu-bugs the days I've mentioned and join the fun.

General Questions

rodolfo: QUESTION: Sometimes it's hard to describe a bug in English, specially when it's about the system behavior. In these cases, there would be better to upload a video, demonstrating the bug and how it happens. Is there any idea to make this possible?

Pedro Villavicencio: Yes, you can do it, the more information you can provide us the better. There's a program called istanbul that allow you to record things happening on your desktop and if you don't know how to explain what's happening, a video is always a good thing.

Wrap Up

Pedro Villavicencio: OK so we're running out of time. Everyday is perfect day for triaging so don't wait till hug day!

Iulian Udrea: Yup, thanks everyone!

Pedro Villavicencio: thanks you all

Transcribed by Patrick Kilgore

CategoryBugSquad