Ubuntu Wiki

Ubuntu Open Week - Bug triage - Brian Murray & Pedro Villavicencio - Mon, Oct 22, 2007

19:07 < pedro_> ok here we go then
19:08 < pedro_> hello everyone! and welcome to the bug triage session
19:08 < pedro_> my name is Pedro Villavicencio and i'm here with Brian Murray
19:08  * bdmurray waves
19:08 < pedro_> we both work for Canonical in the QA Team
19:09 < squish> * w00t QA
19:09 < pedro_> probably all of you guys are wondering what's "triage"
19:09 < pedro_> what does that means
19:09 < pedro_> In a hospital "triage" is the process of separating the very badly wounded from those who are lightly wounded
19:09 < pedro_> In the Free Software/Ubuntu World, it's the process of separating and identifying bugs that are most severe and most useful for the developers
19:10 < pedro_> and the bugs become triaged by gathering more information about the bug itself
19:10 < pedro_> setting their status
19:10 < pedro_> setting their importance
19:10 < pedro_> and identifying duplicates of it
19:10 < pedro_> there's no blood in the process !
19:11 < pedro_> there's quite few teams in ubuntu that triage bugs
19:11 < pedro_> the most general of these is the Ubuntu Bug Squad
19:12 < pedro_> there's info about how to join the Ubuntu Bug Squad here https://wiki.ubuntu.com/BugSquad/GettingInvolved
19:12 < pedro_> if you need help triaging a bug or want to discuss a bug or best practices, most of members of the bug squad are usually accessible in #ubuntu-bugs here at freenode
19:13 < pedro_> and of course if you don't like too much chatting you can find us in the ubuntu-bugsquad mailing list
19:13 < pedro_> which is listed at http://lists.ubuntu.com
19:14 < pedro_> ok first step for doing some triage is of course having bugs
19:14 < pedro_> one way that bugs are reported about Ubuntu is by someone going to the Launchpad website and finding https://launchpad.net/ubuntu/+filebug
19:15 < pedro_> if you go to http://bugs.launchpad.net/  you'll see a red button on the right side of the screen
19:15 < pedro_> with a white label "Report a bug"
19:15 < pedro_> then you'll be asked for a summary and then for a package and further information regarding the bug
19:16 < pedro_> the process itself is very free form though and can lead to incomplete reports or ones without a package
19:16 < pedro_> another way for a bug to be reported to launchpad is by someone using the "help -> report a problem" item
19:16 < pedro_> in every application of ubuntu
19:17 < pedro_> this process will collect the information about the version of Ubuntu the reporter is using, the application name and also it's version
19:17 < pedro_> a report filed that way may be much more complete and they are marked with the apport-bug tag
19:18 < pedro_> you can find all of them here https://launchpad.net/ubuntu/+bugs?field.tag=apport-bug
19:20 < bdmurray> Now that we know where bug reports come from and how they get reported about Ubuntu we look at how to improve a bug report
19:20 -!- mode/#ubuntu-classroom [+o Amaranth] by ChanServ
19:20 < bdmurray> An important part of triaging bugs is ensuring that the bug is valid, is associated with a package, is well described and contains enough information for a developer to know it is a valid bug and start working on it.
19:20 -!- mode/#ubuntu-classroom [-v mrevell-dinner] by Amaranth
19:21 -!- mode/#ubuntu-classroom [+v bdmurray] by Amaranth
19:21 -!- mode/#ubuntu-classroom [+v pedro_] by Amaranth
19:21 <+bdmurray> Detailed information about this can be found at https://wiki.ubuntu.com/Bugs/Improving
19:22 <+bdmurray> Parts of the process include identifying the package the bug is about and the version the reporter noticed it on
19:22 <+bdmurray> As pedro_ sometimes bugs are submitted without a package
19:22 <+bdmurray> A listing of these can be found at http://tinyurl.com/22gw9k .  In this list of bugs you'll notice that the package is just "--"
19:23 <+bdmurray> Looking at the one of the bugs we will see that it affects "Ubuntu".
19:23 <+bdmurray> An easy thing we can do to help the bug along is to assign it to a package.
19:24 <+bdmurray> We have some documentation about determining the package at https://wiki.ubuntu.com/Bugs/FindRightPackage .
19:24 <+bdmurray> We can modify the package a bug is assigned to by clicking on the bug's current status, importance or the downward arrow in the far right side of the package row.
19:25 <+bdmurray> This will reveal a new area of the bug report where you can see the package box is empty.
19:25 <+bdmurray> In that box you can type a package name directly or click on the "Choose ..." hyperlink which will reveal a search for a package dialog.
19:25 <+bdmurray> There can also be bug reports without a specific version of Ubuntu or the package the bug is about.
19:25 <+bdmurray> As there are multiple versions of Ubuntu currently out, Dapper, Edgy, Feisty and Gutsy, finding out the affected release improves the bug report too.
19:26 <+bdmurray> Also determining the version of the package the bug was discovered with helps to improve the report.
19:26 <+bdmurray> Two ways to find out the package version on an installed system are using 'dpkg -l $pkgname' in a terminal and by using Synaptic to search for the package name and looking in the installed version column.
19:27 <+bdmurray> Another critical part of improving a bug report is ensuring that there are detailed steps to reproduce the bug.
19:27 <+bdmurray> This helps other triagers and developers recreate the bug and study it more.
19:27 <+bdmurray> The steps should be broken down individually and as detailed as possible, it is better to have too much information rather than not enough.
19:28 <+bdmurray> I've triaged a fair bit of bugs and one time I saw a reporter add a screencap of their bug as an attachment.
19:28 <+bdmurray> That bug was quite easy for me to recreate!
19:29 <+bdmurray> We can take a couple of questions at this point.  Are there any questions about what we have covered so far?
19:29 <@popey> yes
19:30 <@popey>  < ubuntu_demon> QUESTION: Do you have to be a member of ubuntu-bugsquad to triage bugs ?
19:30 <+bdmurray> No, you don't have to be a member of the team to triage bugs.  Anyone can help in the triaging process!
19:31 < squish> How do you deal with security bugs that are hazardous to expose to the public intially?
19:31 <@Amaranth> squish: #ubuntu-classroom-chat
19:31 <@popey> squish: please ask questions in #ubuntu-classroom-chat
19:31 <@popey> < jkimball4> QUESTION: Are bugs related to a version other than the current stable pointless to triage?
19:31 <+bdmurray> It is possible to report a bug as Private where the visibility of the bug then becomes limited.
19:32 <+bdmurray> No, it is possible that the bug still exists in the latest release so getting the steps to recreate the bug and trying to recreate the bug in the latest release is still valuable.
19:33 <+bdmurray> Okay, moving on now.
19:33 <+bdmurray> Well have some time for more questions at the end.
19:33 <@popey> just say when you want more questions
19:33 <+bdmurray> Every bug has a "Status" and there are currently 9 of these available in Launchpad.
19:34 <+bdmurray> they include New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Won't Fix, Fix Committed, and Fix Released. We will just cover their meaning briefly.
19:34 <+bdmurray> When a bug is first reported the status of the bug is New meaning that the bug report has not been acted upon. These are good candidates for triaging.
19:35 <+bdmurray> A bug report that has a status of Incomplete means that the bug report is missing information. Missing information can include the version of Ubuntu or the version of the package, steps to reproduce the bug report.
19:35 <+bdmurray> A Confirmed bug report is one that someone, other than the original reporter, has been able to reproduce or one that has the minimum debugging information for that package available.
19:35 <+bdmurray> A Triaged bug is one that should have enough information for a developer to start working on a fix for the bug. This status can only be set my a member of the ubuntu-bugcontrol, formerly the ubuntu-qa, team.
19:36 <+bdmurray> An In Progress bug is one that a developer is working on fixing the bug.
19:36 <+bdmurray> An Invalid bug report is one that was determined not to be a bug or one that did not have enough information whether or not it was a bug.
19:36 <+bdmurray> More information about the other statuses can be found at https://wiki.ubuntu.com/Bugs/Status
19:37 <+bdmurray> The statuses most commonly set by members of the Bug Squad are Incomplete, Confirmed and Invalid.
19:37 <+bdmurray> You would use the Incomplete status when gathering more information and asking the reporter a question.
19:38 <+bdmurray> Confirmed after you have everything needed.
19:39 <+bdmurray> The status of the bug report can be modified by clicking on the bug's current status at the top of the bug report.
19:39 <+bdmurray> This will reveal places for you to assign the bug to a package, mentioned previously, and set the status of the bug report.
19:39 <+bdmurray> You can also add a comment to the bug report which will show up in the bug's web page and be e-mailed to subscribers of the bug.
19:40 <+bdmurray> So to triage a bug we would add a comment asking for more information and set the bug to Incomplete.
19:41 <+pedro_> great, so what if you're triaging a crash report
19:41 <+pedro_> and the trace isn't really good of
19:41 <+pedro_> and if there's some user that is having problems with his sound card
19:42 <+pedro_> for that kind of issues we have made some debugging information for specific packages and problems available at https://wiki.ubuntu.com/DebuggingProcedures
19:42 <+pedro_> the debugging pages contain questions that you will need to ask to the reporter
19:42 <+pedro_> in order to make the bug more complete
19:43 <+pedro_> One helpful thing to do when asking questions are making each question separate line so they are not missed
19:44 <+pedro_> Since we want to avoid to have more than one triager working on the same bug, we don't want to duplicate the job, do we?
19:44 <+pedro_> it's a good idea to assign the bug to yourself, this is done by selecting the "Me" option in the "Assigned to" area in the report
19:44 <+pedro_> and please do so :-)
19:45 <+pedro_> once you have the bug assigned, you'll be receiving e-mails with any activity in the report
19:45 <+pedro_> for example: another bug was marked as a duplicate
19:45 <+pedro_> the reporter just answered your questions
19:45 <+pedro_> another person can confirm the bug, etc, etc
19:46 <+pedro_> if you want to see the list of bugs that are assigned to you, launchpad has a nice page located at https://launchpad.net/people/+me/+assignedbugs
19:46 <+pedro_> of course you should replace the "me" by your launchpad username :-P
19:47 <+pedro_> After your job as a triager is done, which basically means that the bug has enough information and you already moved the status to confirmed
19:47 <+pedro_> you should unassign yourself by selecting "Nobody" in the "Assigned to" area
19:48 <+pedro_> and if you want to continue receiving emails about the bug activity you might want to subscribe to the report by activating the "E-mail me about changes to this bug report" option at the bug page and then just click on Save Changes
19:48 <+pedro_> ok, can we take some questions?
19:50 <+pedro_> popey, may you fire us with questions? :-)
19:50 <@popey> sure
19:51 <@popey> < mbt> QUESTION:  Are there published standards for determining the severity of a bug as part of the triage process?
19:51 <+pedro_> mbt, yes we have a wiki page about that and you can read it here: https://wiki.ubuntu.com/Bugs/Importance
19:52 <+pedro_> there's also one explaining the status at https://wiki.ubuntu.com/Bugs/Status
19:52 <+pedro_> ok, next
19:52 <@popey> < squish> How do you deal with security bugs that are hazardous to expose to the public intially? 
19:52 <+bdmurray> The importance of a bug can be set by a member of the ubuntu-bugcontrol team.  In the event that you are not a member of the team feel free to bring the bug up on the mailing list or in #ubuntu-bugs.
19:53 <+pedro_> popey, wasn't that already answered? :-P
19:53 < nxvl> yes it was
19:53 <@popey> sorry, re-asked
19:53 <@popey> < public_void> QUESTION: Can people submit bug fixes with reports? Does this make the process easier?
19:53 <+pedro_> public_void, of course they can! that's the perfect scenario!
19:54 <+bdmurray> Even linking to a patch upstream is very helpful.
19:54 <+pedro_> yep, ok, next
19:54 <@popey> < sourcercito> QUESTION: when we're done recolecting information about a bug, how do we now to whom assign the bug to be take care of.
19:56 <+bdmurray> For the most part bugs should only be assigned to people when they are working on them.
19:56 <+bdmurray> Each package has subscribers to it and receive information about the bug reports.
19:56 <+bdmurray> er, and they
19:57 <+bdmurray> Does that answer your question sourcercito?
19:57 < sourcercito> bdmurray, yes, thanks
19:57 <@popey> < ttread> QUESTION: For bugs in an upstream package, is it best to report in launchpad, in the upstream project's bugracker, or both?
19:57 <+pedro_> ttread,  that's the greatest thing about launchpad
19:58 <+pedro_> if you find a bug in an upstream package you can fill the bug in the upstream tracker
19:58 <+pedro_> and then linking the bug with launchpad
19:58 -!- mode/#ubuntu-classroom [+o Mez] by ChanServ
19:59 <+pedro_> so if the bug upstream get fixed you'll be notified about that
19:59 <+pedro_> the same if the bug upstream needs more info
19:59 <+pedro_> so yeah, you can do both if you want to :-)
20:00 <@popey> < UKHack> <QUESTION> I'm relatively short of time, but I'd like to help out with the triage effort - what would you advise me to do to make the most of my time?
20:01 <+bdmurray> As mentioned previously some bugs come into without a package and assigning them to a package doesn't require much commitment / time.
20:01 <+bdmurray> Also looking at the apport-bug tagged bugs may make the most of your time as they will already have a lot of information in them.
20:02 <+bdmurray> I think that is all we have time for here, however pedro_ and I will be in ubuntu-bugs for a while and happy to take questions there
20:03 <@popey> theres 5 mins and 3 questions left
20:03 <+bdmurray> popey: okay let's give a try then and hope BenC doesn't get mad
20:03  * BenC is fine :)
20:03 <@popey> < BonesolTeraDyne> QUESTION: In the wiki article, the bug severity levels mention small or large "portions" of users as criteria. What percentages would be considered small or large?
20:04 <+bdmurray> Determing the scope of a bug and the number of affected users can be tricky.
20:05 <+bdmurray> Some things to consider are "Is the application installed by default?"
20:05 <+bdmurray> "Is the bug in a common operation of the application?"
20:06 <+bdmurray> If it is hardware related "How prevalent is the hardware?"
20:07 <@popey> ok, we're about out of time
20:07 <+bdmurray> But these are estimates and it is largely a judgement call.
20:07 <@popey> thanks to bdmurray and pedro_ !
20:07 <+pedro_> thanks all for the attention ! :-)
20:07 <+bdmurray> Thanks for having us.  If you any furhter questions join us #ubuntu-bugs or use the mailing list!
20:08 < ubuntu_demon> thanks :)
20:08 <@popey> cool
20:08 < nxvl> thanks
20:08 < squish> *applause