BugTriaging

Ubuntu Open Week - Bug Squashing!(How To Triage bugs in Ubuntu) - Pedro Villavicencio - Tue, Nov 4th, 2008

(02:02:02 PM) pedro_: Hello everybody!, my name is Pedro Villavicencio I'm from the lovely Chile and i work for Canonical as a Desktop QA Engineer
(02:02:19 PM) pedro_: Today i'm going to talk to you a bit about the Bugsquad and the Triage process
(02:02:49 PM) pedro_: if you have questions just post them to ubuntu-classroom-chat
(02:03:07 PM) pedro_: ok so let's roll
(02:03:52 PM) pedro_: If you ask what's the Ubuntu Bugsquad is well the Bugsquad is the first point of contacts for the bugs filed in Ubuntu
(02:04:24 PM) pedro_: we keep track of them and try to make sure that major bugs do not go unnoticed by developers
(02:05:00 PM) pedro_: we do this with a process called "Triage"
(02:05:30 PM) pedro_: Working with the Bug Squad it's an excellent way to start helping and learn a lot about Ubuntu and it's infrastructure
(02:05:51 PM) pedro_: You do not need any programming knowledge to join the team
(02:06:22 PM) pedro_: in fact it is a great way to return something to our precious Ubuntu project if you cannot program at all
(02:07:02 PM) pedro_: We have a team on LP https://launchpad.net/~bugsquad it's an open team which means that everybody can join
(02:07:47 PM) pedro_: we also have couple of IRC Channels where bugs are discussed #ubuntu-bugs, and where the new bugs are  announced #ubuntu-bugs-announce
(02:08:35 PM) pedro_: there's also a mailing list https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad that we use for all kind of coordination and discussions
(02:10:09 PM) pedro_: Ok so, Bug triage is an essential part of Ubuntu's development. And daily we get a *huge* number of bugs so we're always looking for help
(02:10:24 PM) pedro_: Triaging consists of a few things:
(02:10:45 PM) pedro_: * Responding to new bugs as they are filed
(02:11:18 PM) pedro_: * Ensuring that new bugs have all the necessary information
(02:11:58 PM) pedro_: We often got bugs with titles and summaries like "This Does not work" or "I don't know" which aren't really helpful to the developers in order to fix them
(02:12:33 PM) pedro_: the summary is one of the things that should be improved too when you face a bug report
(02:13:01 PM) pedro_: because later on it'll be more easy to search trough them if you have a really good one
(02:14:18 PM) pedro_: summaries like the one previous described doesn't help too much and make the work of the developers really hard so we should change that to reflect what's really is going on with the bug for example:
(02:15:27 PM) pedro_: having a summary with "gedit crashed while trying to open an xml file" is way better to having one like "it just crashed!"
(02:16:47 PM) pedro_: bugslayr: yes and i'll explain that further ;-)
(02:17:48 PM) pedro_: Ok in order to gather more information for reports we have the debugging pages https://wiki.ubuntu.com/DebuggingProcedures
(02:18:08 PM) pedro_: which contains information on how to get more information for packages in Ubuntu like firefox, openoffice.org, the kernel, apache, etc.
(02:18:40 PM) pedro_: But based in my experience most of new triagers don't know what to ask the very first times they're doing triage work
(02:19:04 PM) pedro_: for example if a bug isn't not described too well, you know one of those doesn't work reports, what you'd ask to the reporter?
(02:20:30 PM) pedro_: well for those kind of things we have a really neat page at https://wiki.ubuntu.com/Bugs/Responses
(02:20:43 PM) pedro_: with a lot of stock responses you can use for your daily triage work
(02:21:28 PM) pedro_: as per the example you can use the "Not described well" stock response: https://wiki.ubuntu.com/Bugs/Responses#Not%20described%20well
(02:22:16 PM) pedro_: Another triage process is:
(02:22:22 PM) pedro_: * Assigning bugs to the proper package
(02:22:59 PM) pedro_: This is also another important part of the triage process if you look at http://tinyurl.com/bugswithoutahome you'll see ~1800 reports without a package assigned to it
(02:23:52 PM) pedro_: almost every report on that list needs to be assigned to one with the exception of reports like "needs-packaging" which are request for new packages
(02:24:16 PM) pedro_: I'd say that assigning bugs to packages is one of the easier tasks in the triage process and if you want to start doing triage you probably want to start triaging them
(02:25:08 PM) pedro_: you can also find more info about this on https://wiki.ubuntu.com/Bugs/FindRightPackage
(02:26:05 PM) pedro_: <jpugh> QUESTION: I noticed there are many bugs that are VERY old. Do these ever get cleaned up or closed due to lack of response?
(02:27:28 PM) pedro_: Incomplete bugs are closed after 4 weeks if they don't have a response
(02:27:43 PM) pedro_: if you find some that aren't yet , please do close it ;-)
(02:28:36 PM) pedro_: If you found a really old report in a New status you probably want to ask to the reporter if the bug is still reproducible with a newer version of Ubuntu and set the status to Incomplete
(02:29:05 PM) pedro_: QUESTION: Is there an easy way to determine the bugs that do not have packages assigned?
(02:30:44 PM) pedro_: yes, if you look at this bug for example https://bugs.edge.launchpad.net/ubuntu/+bug/291998
(02:30:48 PM) ubot5`: Launchpad bug 291998 in ubuntu "Kubuntu 8.10 DNS problem" [Undecided,New]
(02:31:21 PM) pedro_: you'll see that it only have a affects "Ubuntu" package selected, that bug doesn't have a package and you might want to triage it with the steps previously described (asking for more info, etc)
(02:32:41 PM) pedro_: if you look at the launchpad list of bugs, you know the typical one, go to -> https://bugs.launchpad.net/ -> click on search bugs -> and later order them by newest first
(02:33:29 PM) pedro_: you'll see a column that said "In", basically the one that says "Ubuntu" is a bug without a package
(02:34:06 PM) pedro_: another process of the triage is:
(02:34:14 PM) pedro_: * Confirming bug reports by trying to reproduce them
(02:34:30 PM) pedro_: * Setting the priority of bugs reports
(02:34:55 PM) pedro_: * Searching for and marking duplicates in the bug tracking system, which is very important since a big quantity of reports we got are duplicates.
(02:35:36 PM) pedro_: * Sending bugs to their upstream authors, when applicable and the awesome Jorge Castro have a session tomorrow about this
(02:36:13 PM) pedro_: * Cross-referencing bugs from other distributions
(02:36:33 PM) pedro_: And * Closing old reports, like the Incompletes one I've explained before
(02:36:51 PM) pedro_: All of these activities help the bug get fixed and subsequently making Ubuntu even better
(02:37:12 PM) pedro_: As soon as you have done enough good triage work, you can apply to the ubuntu-bugcontrol team
(02:37:30 PM) pedro_: which is the one with more rights over the reports
(02:37:47 PM) pedro_: so basically you can see the Private reports, change the Importance of the bugs and set a couple of bug status (Triaged, Won't Fix) we will talk about both in a min
(02:39:10 PM) pedro_: the requirements for join the team are available here: https://wiki.ubuntu.com/UbuntuBugControl
(02:39:11 PM) pedro_: * Bug Status:
(02:39:28 PM) pedro_: We currently have 9 status, they are
(02:40:15 PM) pedro_: New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Fix Committed, Fix Released and Won't Fix
(02:40:40 PM) pedro_: The first ones are kinda clear, New status means that no one has triaged or confirmed the bug
(02:41:03 PM) pedro_: <homy> QUESTION: when we start to triage a bug and leave a comment, do we automatically get email if new comments area added? Or do we need to subscribe the bug manually?
(02:41:57 PM) pedro_: homy: if you start doing triage you should subscribe to the bug you're triaging, just click on the checkbox that says "E-mail me about changes to this bug report" and you're done
(02:42:58 PM) pedro_: after that, you'll receive an email if someone makes a change to the report, add a new comment, etc
(02:43:27 PM) pedro_: The Incomplete status means that the bug is missing some information for example a debugging backtrace of a crash or steps in order to trigger the bug
(02:43:58 PM) pedro_: A Confirmed is almost self explanatory, someone else than the reporter have the same bug, please  please please pleeease only confirm other people bugs not your own ones :-)
(02:44:49 PM) pedro_: The Triaged state is set by a member of the Ubuntu Bug Control team (hopefully you in a few weeks ;-) ) when they think that the bug has enough information for a developer to start working on fix the issue
(02:45:47 PM) pedro_: If a bug was marked as Triaged and a Developer is working on fixing the bug, that report needs to be marked as "In Progress", because there's a person working on it
(02:46:49 PM) pedro_: If that developer committed the fix to a bzr branch the bug needs to be marked as Fix Committed
(02:48:09 PM) pedro_: And when that fix get released the status of the bug is changed to Fix Released
(02:48:24 PM) pedro_: <fluteflute> QUESTION: bugs are often marked as fix commited against ubuntu packages when actually the fix is commited upstream (going by the policy at https://wiki.ubuntu.com/Bugs/Status). Is this acceptable?
(02:49:49 PM) pedro_: fluteflute: good questions, for some teams in Ubuntu, yes, launchpad currently doesnt have a method to know which bugs are fixed upstream in their bug list
(02:49:57 PM) pedro_: for example if you look at https://bugs.edge.launchpad.net/ubuntu/+source/gedit
(02:50:35 PM) pedro_: at the desktop team we mark the bugs fixed upstream as fix committed
(02:50:49 PM) pedro_: so we can look at that list and known which bug is fixed upstream and which isn't
(02:51:37 PM) pedro_: as soon as launchpad provides us of a way to see that on the default list of bugs we can probably discuss again the Fix Committed status ;-)
(02:52:18 PM) pedro_: will do a quick review of the Importances of a bug since we don't have enough time
(02:52:47 PM) pedro_: the Importances can only be changed by the bug control team
(02:53:13 PM) pedro_: we have 6 importances, Undecided, Wishlist, Low, Medium, High and Critical
(02:53:25 PM) pedro_: and you can read more about them here: https://wiki.ubuntu.com/Bugs/Importance
(02:53:39 PM) pedro_: One of the nicest thing the Ubuntu Community do is the
(02:53:41 PM) pedro_: Hug days!
(02:53:53 PM) pedro_: he very brave Bugsquad team also organize Bug Days also known as Hug Days (triage a bug and win a hug!)
(02:53:59 PM) pedro_: s/he/the
(02:54:19 PM) pedro_: well the idea of a hug day is to work together with the bugsquad and project maintainers on a specific task, weekly we organize two hug days
(02:54:36 PM) pedro_: one the Tuesday and another one the Thursdays, today we're running the New bugs without a package since Intrepid came out bug day. If you want to join us at Hug Days just come to #ubuntu-bugs and join the fun!
(02:55:03 PM) pedro_: If you want to propose a hug day you can also do it just say it at the bugsquad mailing list and take a look to the proposed hug days in case the hug day you're proposing is already on the list, that list is available here: https://wiki.ubuntu.com/UbuntuBugDay/Planning
(02:55:26 PM) pedro_: and if you also want to help us to organize that day (which i think would be the case) you might want to read the organizing a hug day page https://wiki.ubuntu.com/UbuntuBugDay/Organizing
(02:55:38 PM) evan_: pedro_:  question: what is the best to do ? apply a patch on a broken program ( like gnome-session ) or wait untill its fixed?
(02:56:30 PM) pedro_: ok we have 5 minutes left, so 5-a-day!
(02:56:47 PM) pedro_: 5-A-Day means everybody will do 5 (or more) bugs a day every day, you can look for 5-a-day stats at http://daniel.holba.ch/5-a-day-stats/ and for example if you want to work with your LoCo team on a specific task or do a bug jam session you can use 5-a-day too to show other people your team progress
(02:57:03 PM) pedro_: in Chile we use 5-a-day to keep track of our Monthly bug jam sessions if you look to almost the bottom of the page you'll see what i'm talking about
(02:57:38 PM) pedro_: last saturday we had our bug jam for November, the tag used there was bugjam-november-08-chile, so feel free to use this for doing bug activities with your loco team!
(02:57:59 PM) pedro_: if you have questions on how to organize them just mail us or ask us in the #ubuntu-bugs channel
(02:58:26 PM) pedro_: <homy> QUESTION: when exactly is a "confirmed" bug changed to "triaged"? I mean, you can't know if it really is enough information before a developer starts working on it.
(02:58:56 PM) pedro_: homy: for example if you don't have sound with a xxx sound card and someone has the same problem with the same card he probably is going to mark the bug as confirmed
(02:59:13 PM) mode (+o popey ) by ChanServ
(02:59:16 PM) pedro_: but since the bug doesn't have more info that two persons having the same problem , ie: no logs of your card, etc
(02:59:43 PM) pedro_: that bug needs to be triaged by someone and request all the information as soon as the bug has all the info requested by the bug triager
(02:59:47 PM) pedro_: the bug is changed to triage
(02:59:55 PM) pedro_: we're running out of time
(03:00:02 PM) pedro_: thanks a lot to everyone and happy triaging!

MeetingLogs/openweekintrepid/BugTriaging (last edited 2008-11-04 21:51:02 by pool-70-16-60-167)