Ubuntu Wiki

Ubuntu Open Week - Triaging Bugs With Launchpad - Bjorn Tillenius - Thu, Apr 26, 2007

see also Monday Session.

TZ UTC-4

(03:02:34 PM) BjornT: Ok, so let's start this session about triaging bugs with Launchpad.
(03:02:53 PM) BjornT: I'm Bjorn Tillenius, the lead developer of the bug tracking part of Launchpad.
(03:03:36 PM) BjornT: This session will be more or less a repeat of the previous one on Monday, but I'll be giving more priorities to questions, trying to answer as many as possible.
(03:04:30 PM) BjornT: Also, this time Brian Murray (bdmurray) from the Ubuntu BugSquad is here to help me answer questions.
(03:05:17 PM) BjornT: At least he should be joining us shortly.
(03:05:25 PM) bdmurray: Yes, hello.
(03:05:33 PM) BjornT: Cool.
(03:05:39 PM) BjornT: For those of you that don't already know, Launchpad (https://launchpad.net) is a web application for managing software projects, i.e. it provides bug tracking, feature tracking, code hosting, and more.
(03:05:53 PM) BjornT: A lot more could be said about Launchpad. If you're intested in knowing more, mrevell gives an introduction to Launchpad tomorrow.
(03:06:16 PM) BjornT: First of all, let's define "triage", since it's not a commonly used word. The
(03:06:19 PM) BjornT: dictionary defintion is:
(03:06:30 PM) BjornT:     1.   the process of sorting victims, as of a battle or disast er, to determine medical priority in order to increase the number of survivors.
(03:06:34 PM) BjornT:      2.   the determination of priorities for action in an emergency.
(03:07:02 PM) BjornT: When I talk about triaging here, it has a slightly different meaning, though. :) It involves prioritisation of bugs, but more importantly it means to prepare the bug reporter for a bug fixer, so that he can focus on what he can do best.
(03:07:26 PM) BjornT: Now, let's talk about getting started with triaging bug.
(03:07:33 PM) BjornT: Triaging bugs is a great way of getting involved with a project. It doesn't require that you know how to code, and pretty much anyone can learn how do it.
(03:07:46 PM) BjornT: Doing this session actually made me realize that it can be quite hard to know how to get involved with triaging bugs, but don't let that put you off!
(03:08:00 PM) BjornT: If you just contact the right people, they will most of the time be happy that you want to help, since that can improve the experience for their bug reporters.
(03:08:27 PM) BjornT: Do contact someone related to the project before triaging bugs, though. Each project has their policy of how to triage bugs, and it might not be that well documented. It's important to have a good dialog, so that you know that you are triaging correctly.
(03:08:52 PM) BjornT: As a bug reporter, you want that someone cares about your bug report, so having bug triagers that can reply promptly to new bug reports is a great asset for a project.
(03:09:11 PM) BjornT: By triaging bugs you'll also help the developers focus more on bug fixing, and less on talking.
(03:09:38 PM) BjornT: There are a few different ways you can triage bugs; some require more knowledge and authority than the others.
(03:09:46 PM) BjornT: I'd say the two most common meanings of triaging are:
(03:09:49 PM) BjornT:     - making sure that the bug report contains enough information
(03:09:54 PM) BjornT:      - prioritize the bug
(03:10:00 PM) BjornT: The latter can be quite difficult to do, and it requires that you are trusted by the project, so i'll be concentrating on the first point, which basically means to make the bug report good enough so that more experienced people can prioritize and fix the bug.
(03:10:26 PM) BjornT: So, what kind of information should the bug report contain?
(03:10:37 PM) BjornT: Basically it should contain enough information so that someone could reproduce the bug, and it should also clearly state what the actual bugs is.
(03:10:56 PM) BjornT: i.e., it should contain the answers to the following questions:
(03:11:00 PM) BjornT:     - what did you do?
(03:11:04 PM) BjornT:      - what happened?
(03:11:08 PM) BjornT:      - what did you expect to happen?
(03:11:16 PM) BjornT: But this is not the only information that is needed;  each project have their set of requirements and guidelines as to what exactly a bug report should contain.
(03:11:37 PM) BjornT: So before starting to triage bugs for a project, you should get in contact with the people that are dealing with bugs within the project.
(03:11:40 PM) BjornT: Your best bet is usually to look at who's the designated "Bug Contact"
(03:11:43 PM) BjornT: of the project, find them on IRC or drop them an e-mail.
(03:12:05 PM) BjornT: Since this is *Ubuntu* Open Week, let's take Ubuntu as an example. Note that most of the things I will talk about here apply to any project using Launchpad, not just Ubuntu.
(03:12:20 PM) BjornT: If you look at https://launchpad.net/ubuntu you can see that the 'Ubuntu Bugs' team is the bug contact. If you follow that link to https://launchpad.net/~ubuntu-bugs, you can see that you shouldn't join that team, though!
(03:12:58 PM) BjornT: The ubuntu-bugs team is used mostly to get all the bug notifications sent to a mailing list.
(03:13:03 PM) BjornT: On the same page you can see that the Ubuntu QA Team is listed as the owner, so if you'd follow that link you'd be pointed to the Ubuntu BugSquad, which is that team that deals with bugs in Ubuntu.
(03:13:22 PM) BjornT: https://wiki.ubuntu.com/BugSquad contains all information you need to join the team and start triaging Ubuntu bugs. Don't be shy, they will appreciate any help you can give them. :) They usually hang out in #ubuntu-bugs here on freenode.
(03:13:46 PM) BjornT: But don't go off reading all that information just yet, though, since it would take most of this session. Instead I will talk a bit about triaging bugs here.
(03:14:14 PM) BjornT: So, now that we know who we should talk to about triaging bugs, we can talk about picking which bugs to triage.
(03:14:31 PM) BjornT: If you look at https://bugs.launchpad.net/ubuntu you can see that there's a great deal of Unconfirmed bugs. It's those bugs that you want to turn to either Confirmed or Rejected.
(03:15:10 PM) BjornT: Confirmed basically means that the bug report contains enough information for someone to fix the bug, and Rejected means that it's not really a bug, for example, it could be a support request disguised as a bug report.
(03:15:36 PM) BjornT: When you triage bugs, you start to have a conversation with the bug reporter. This is important work, since it gives the bug reporter someone to talk to, and it shows him that someone does care about his bug report.
(03:16:00 PM) BjornT: Be sure to be polite to the reporter, though :), we don't want him to get a bad impression of the community.
(03:16:07 PM) BjornT: In order to avoid more than one people triage the same bug, it's a good idea to assign the bug you want to triage to yourself. This gives you a list of bugs you need to pay extra attention to at https://launchpad.net/people/+me/+assignedbugs.
(03:16:43 PM) BjornT: Assigning the bug to yourself also makes it easier for triager to find bugs you want to triage, since you can exclude bugs that are assigned to someone.
(03:17:06 PM) BjornT: To find bugs to triage, you can go back to https://bugs.launchpad.net/ubuntu and click on the "Advanced search" link, which will allow you to filter the bug listing in a great number of ways.
(03:17:25 PM) BjornT: In Ubuntu, bugs are considered untriaged if they are Unconfirmed, have an Undecided importance, and doesn't have an assignee.
(03:17:45 PM) BjornT: So you should make sure that no other statuses or importances are checked, as well as making sure that "Nobody" is specified as the assignee.
(03:18:04 PM) BjornT: After you've done this and clicked on "Search", you probably want to bookmark that page.
(03:18:16 PM) BjornT: When you have the list of bugs, it's a good idea to open each bug you want to triage into a new browser tab. That makes it easier to get back to the bug listing after you're done with the bug.
(03:18:40 PM) BjornT: Now, let's talk about how you actually triage a bug report that you've found.
(03:18:46 PM) BjornT: First, you should read through the bug report and make sure that you understand what the bug report is about. If it's unclear, ask the reporter to clarify.
(03:19:12 PM) BjornT: When you ask the reporter something, you should set the status to "Needs Info", so that the reporter (and you) knows that action is required from him.
(03:19:29 PM) BjornT: Sometimes the bug reporter doesn't respond, so if a bug in "Needs Info" hasn't gotten a reply for a while, it's usally a good idea to Reject the bug, since it can't be fixed without knowing more about the problem.
(03:20:00 PM) BjornT: Now, it might not be completely obvious how to change a bug's status, so I'll better tell you how to do it :).
(03:20:26 PM) BjornT: You change the status of the bug by clicking on the package name (e.g.  "amule (Ubuntu)"), which will expand the edit form, where you can edit things like status, assignee, and package name, and you can also leave a comment while editing.
(03:20:58 PM) BjornT: Anyone is allowed to edit the status of a bug, you don't need any special privileges.
(03:21:09 PM) BjornT: Now, let's get back to actually triaging the bug.
(03:21:31 PM) BjornT: There are a number of different things you can to do. A good first step is to try to reproduce the bug. If you don't know what steps are necessary, you should ask the bug reporter for more information.
(03:21:56 PM) BjornT: Now, after he's given all the information, it will be there in the comments. But sometimes there are a great number of comments in a bug, so the needed information can be hard to find there.
(03:22:23 PM) BjornT: So, to make it easier to find, Launchpad allows you to edit the bug description, by clicking on the "Edit description/tags" link in the action menu to the left.
(03:22:55 PM) BjornT: Moving the important information to the description will make it much easier for the next person looking at the bug to understand the bug.
(03:23:43 PM) BjornT: The next thing you should do is to try to decide whether the bug is filed under the correct source package. In Launchpad bugs are associated with source packages, not binary packages, and it can be hard for people to know on which package to file the bug on.
(03:24:05 PM) BjornT: If a bug doesn't have a package at all, or an incorrect one, it could lead to the bug not getting looked at by the people that should.
(03:24:25 PM) BjornT: Also, each package generally have few different guidelines as to what information a bug should contain, and it narrows down the scope of possible duplicate bugs.
(03:24:58 PM) BjornT: You can change/set the source package on the same form as editing the status, which is expanded by clicking on the package name on the bug page. You can find more information about finding the right source package at https://wiki.ubuntu.com/Bugs/FindRightPackage.
(03:25:43 PM) BjornT: Let's break for a quick question.

< zorglu_> QUESTION: is there some kind of voting system ... i mean something which say 1 people reported this bug but 300 others have seens it as well ?

• no, there's no such voting system. but you if someone experiences a bug, he might subscribe to the bug, so you can look at how many duplicates and subscribers a bug has.

< Belutz> QUESTION: should we triage bugs for the recent release? or all. release that is still supported?

• bdmurray: can you answer that one?

  <bdmurray> For all releases that are supported should be triaged. However, it is possible that something might be fixed in Feisty and not get backported to Dapper or Edgy. It is also possible to find bugs about unsupported releases for example Breezy in launchpad.

< dcomsa> QUESTION: what are the conditions to be met, so that a. developer will have a look at a bug report?

• In general, if a bug is Confirmed and have an importance set, it should be good enough for a developer to look at.

  <bdmurray> The information needed for a developer to be successful is dependent on the package the bug is in.

  < Belutz> QUESTION: so if i use feisty now, i can't reproduce bugs that. happened in dapper/edgy so I should leave those bugs to other. people to triage? <bdmurray> To a degree. It is still possible to gather the right information for a bug that happens in Edgy or Dapper you just may not be able to verify or reproduce it. Furthermore you could help find duplicates for Dapper and Edgy without running it.

(03:33:03 PM) BjornT: Ok, let's continue with the session. There'll be more time for questions later.
(03:33:11 PM) BjornT: After you decided that the source package is correct, you can start to search for similar bug reports, to see if the bug has already been reported before.
(03:33:27 PM) BjornT: You should start by going to the package's bug listing, which you can reach by expanding the edit form by clicking on the package name, and then click on the package name next to "Affecting:" to the right in the edit form.
(03:33:44 PM) BjornT: It's good to open this page in a new browser tab, so that you can easily return to the bug report.
(03:33:48 PM) BjornT: On the package bugs page, e.g.  https://bugs.launchpad.net/ubuntu/+source/amule, you can search for bugs that are reported on the amule package. The search will include all the bug reports that include the search words that you specify.
(03:34:12 PM) BjornT: If you found a bug report that is about the same bug as the report you are triaging, you can go back to the latter and indicate that it's a duplicate bug by clicking on "Mark as duplicate" and enter the id of the bug you've found.
(03:35:25 PM) BjornT: It can be hard to identify duplicate bug sometimes, though. The important thing is that the root cause is the same. Sometime two different bugs can appear to be the same, but have different root causes.
(03:36:22 PM) BjornT: e.g., two different bugs could cause the error message "An error occured" to be printed out.
(03:36:51 PM) BjornT: Now, if the bug isn't a duplicate, you can continue making sure that the bug report contains enough information so that a developer can debug what's wrong, ideally without having to request more information for the bug reporter.
(03:37:21 PM) BjornT: The most common thing is to ask the user what version of the related packages he's using. The reporter might not know how to get at this information, so be prepared to tell him how to do it.
(03:37:44 PM) BjornT: Apart from the general version information, each package, or subsystem has their own set of information they want a bug report to contain. For example, bugs involving a USB printer should contain a list of loaded usb modules, as well as some specific log output. The BugSquad can tell you more about this.
(03:38:16 PM) BjornT: Now, since each part of a project is different, it can makes sense to focus on a specific part. This is especially true for large projects like Ubuntu. For example, in Ubuntu you could choose to focus on printing bugs, desktop bugs, firefox bugs, etc.
(03:39:10 PM) BjornT: Focusing on a smaller set of bugs gives you an opportunity to learn more about it, so that you, after a while, can do more advanced triaging, and maybe even fix bugs yourself.
(03:40:12 PM) BjornT: There are usually teams you can join if you want to focus on some specific kind of bugs.
(03:40:37 PM) BjornT: Let's break for some more questions.

< habeeb> QUESTION: Right now I'm using a distro other than Ubuntu. Can I. still help on the bug triaging? What would you suggest to be. sure that I don't mess up stuff?

• <bdmurray> Frequently bug reports come in without all the necessary information to recreate the bug. So you could still ask questions to make sure the right information is gathered. We have a list of standard response at https://wiki.ubuntu.com/Bugs/Responses

< bullgard4> QUESTION: I have started Ubuntu 7.04 Herd4 and when. it announced a crash I would file it to the uggested. channels. Usually I could only add some circumstances under. which the error occurred. I noticed some answers I've got.. But more I could not contribute, I'm afraid. Is this still. helpful?

• <bdmurray> It sounds like you were using apport to report a crash and yes the information it reported was helpful. However, it is best to have the circumstances around the crash reported.

(03:45:02 PM) BjornT: Ok, let's finish off with talking a bit about more advanced triaging, which you can do when you are a bit more experienced.
(03:45:12 PM) BjornT: One example of more advanced triaging is forwarding bugs to other projects.
(03:45:29 PM) BjornT: Most of the time, the bugs reported on Ubuntu, aren't bugs in the actual packaging of the software, but a bug in the software itself, which is better fixed by someone else.
(03:45:50 PM) BjornT: In this case Launchpad allows you to link bug to the other software's bug tracker. For example, if you look at https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/6710 you can see that there are two abiword rows in the "Affects" table, one (upstream), and one (Ubuntu).
(03:46:35 PM) BjornT: The abiword (upstream) one is linked to bug #6857 in abiword's real bug tracker, and when that bug change its status, Launchpad will send a notification it, so that the Ubuntu developer fixing the bug may choose to pull in the upstream fix.
(03:47:05 PM) BjornT: You can create such an (upstream) row by clicking on the "Also affects: +Upstream..." link. There you will first get prompted to enter the name of upstream project.
(03:47:26 PM) BjornT: Launchpad does have some knowledge of which upstream project corresponds to which Ubuntu package, so sometimes you don't have to specify anything at all, and can simply continue linking to the external bug report.
(03:47:57 PM) BjornT: However, if Launchpad doesn't know which project you want to link to, you have to specify the name yourself, and sometimes you even have to register it in Launchpad.  Registering projects in Launchpad for this purpose is ok to do, even if you aren't associated with that project.
(03:49:38 PM) BjornT: When doing this it's good to be aquinted with upstream project. You should always try to be a good upstream community citizen, which will help Ubuntu.

< Belutz> QUESTION: how do we know that the bugs also affect upstream?

• <bdmurray> That's a good question. Some of it is knowing how different Ubuntu's code base for a pacakge is from upstreams. Part of it is also looking to see if the bug has already been reported upstream. Another way to find out would be to ask the packager of the product for Ubuntu.

< RainCT> QUESTION: How can I set that a bug is affecting many Ubuntu. version?

• You can do this by clicking on "Also affects:... +Distribution" That page is used both for saying that a bug affects another distribution (e.g. Debian), as well as saying that it affects another source package.

  <bdmurray> That is not releases of Ubuntu though. oh, wait, misread the question :_

<nevermind_> QUESTION: having timeouts with irq on using synaptics touchpad on my acer travelmate 250, running latest stable ubuntu. had same prob with all linux distris so far, on the web there are a few bootloader tricks, that didnt do for me. tried kernels: 2.6.1x, 2.6.0x, 2.4.x, 2.2.x, and 2.6.20

• maybe you'd like to answer how you deal with bugs affecting more than one ubuntu version? do you care about it?

  <bdmurray> That sounds like a specific bug question and should be asked in #ubuntu-bugs

(03:58:22 PM) bdmurray: For bugs affecting more than one version of Ubuntu it is dependent on the severity of the bug as to whether or not it will be fixed in a previous release.  If a bug is filed on a specific package it is understood that it affects all versions with that version of the package.
(03:58:42 PM) bdmurray: all releases rather
(04:00:29 PM) BjornT: Ok, I think it's time to let the next session begin. Thanks for listening.
(04:00:36 PM) BjornT: To remind you, if you want to start triaging Ubuntu bugs (you really should give it a try), read https://wiki.ubuntu.com/BugSquad and https://wiki.ubuntu.com/Bugs/HowToTriage.
(04:01:17 PM) bdmurray: And feel free to ask me questions in ubuntu-bugs