Ubuntu Open Week - HowTo Triage bugs in Ubuntu - PedroVillavicencio - Thu, Apr 30th, 2009
(04:01:08 PM) pedro_: ok folks as nixternal said my name is Pedro Villavicencio I'm from the lovely Chile and I work for Canonical , my primary focus is on the Ubuntu Desktop Bugs (04:01:34 PM) pedro_: I'll introduce you to the BugSquad and How to Triage Bugs in Ubuntu (04:02:06 PM) pedro_: The Ubuntu BugSquad is the first point of contact for the Bugs filed in Ubuntu, we keep track of them and try to make sure that major bugs do not go unnoticed by the developers/maintainers (04:02:23 PM) pedro_: (btw feel free to ask on ubuntu-classroom-chat i'll pick questions from there later) (04:02:35 PM) pedro_: how we do that? We do something called "Triage" which is a pretty similar process to the one of prioritizing patients based on the severity of their condition (04:02:51 PM) pedro_: Working with the BugSquad it's an excellent way to start helping and learn a lot about Ubuntu and it's infrastructure (04:03:18 PM) pedro_: And No, you don't need any programming knowledge to join the team in fact it's a great way to return something to your lovely Ubuntu project if you cannot program at all (04:03:43 PM) pedro_: There's an open team on Launchpad for the BugSquad https://launchpad.net/~bugsquad everybody can join as said it's an open team (04:04:06 PM) pedro_: We also have a couple of IRC Channels that you might be interested on visit: (04:04:19 PM) pedro_: Where the bugs are discussed: #ubuntu-bugs (04:04:46 PM) pedro_: Where the new bugs are announced: #ubuntu-bugs-announce (04:05:10 PM) pedro_: There's also a mailing list available at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad and we use it for all kind of coordination and discussions (04:05:39 PM) pedro_: if you want to interact with the team those are the right ways to do it (04:06:35 PM) pedro_: <komputes> pedro_: Question: How can we possibly deal with a large number of bugs that have been reported upstream with no action for a few years. What is a good strategy to either having volunteer or paid developers resolves these issues and propose patch (04:07:05 PM) pedro_: well that's not easy, you can either talk with the upstream developers and let them know you concerns or provide patches to get those bugs fixed (04:07:44 PM) pedro_: in free software the people do what they want ;-) and most of people participating on free software projects are volunteers (04:08:16 PM) pedro_: btw there's a talk about Upstream Bug Workflow after mine you might want to bring those questions there as well ;-) (04:08:36 PM) pedro_: ok let's go to the bug triage ! (04:09:11 PM) pedro_: The Bug Triage is an essential part of the Ubuntu's development process which consists of a few things (04:09:53 PM) pedro_: Responding to new bugs as they are filed, if you report something you really want to get some feedback from the other side, responding to those bugs in a short period is pretty important (04:10:10 PM) pedro_: * Ensuring that new bugs contains all the necessary information for the developers/maintainers to work on it and fix that bug (04:10:33 PM) pedro_: This could look like normal to you and probably you do include that information when you're reporting a bug but most of the reports we got doesn't contain that information (04:11:10 PM) pedro_: we often triage reports with summaries like "I don't know!" - "It crashed!" - " Doesn't work" (04:11:39 PM) pedro_: which doesn't help a lot to the developers/triagers, so improving the summary is one of the things that should be done when you are fighting a bug report (04:12:19 PM) pedro_: having one with a summary like "brasero doesn't burn if the disc title contains a & " it's way better than something like "doesn't burn" (04:13:23 PM) pedro_: In order to get more information we have the debugging pages https://wiki.ubuntu.com/DebuggingProcedures which contains information on how to get more information for packages in Ubuntu like Firefox, OpenOffice.org, Apache, Samba, the Kernel, etc. (04:14:22 PM) ***JManGt is back (gone 00:42:59) (04:14:35 PM) pedro_: QUESTION: How can we take care of doing a triage on a large number of new bugs without making the process seem automated, alienating and possibly invalidating or marking as a duplicate erroneously. (04:15:46 PM) pedro_: It's all based on the experience i think, in Ubuntu we indeed triage a *lot* of bugs daily, reading those carefully and if you're in doubt of doing something the best is to ask in the #ubuntu-bugs channel to avoid that kind of problems (04:15:53 PM) pedro_: so don't be afraid to ask (04:16:51 PM) pedro_: Ok, so New triagers often don't really know what to ask when they are taking care of a report (04:17:13 PM) pedro_: ie: the not described well with the "I don't know" titles or summaries, what do you ask there? (04:17:35 PM) pedro_: maybe a "could you describe this a bit further" would help? (04:17:47 PM) pedro_: for those kind of situations we've collecting Stock Responses (04:18:01 PM) pedro_: which are available here: https://wiki.ubuntu.com/Bugs/Responses (04:18:15 PM) pedro_: if you're looking for one that you could use to grab more info well look at the https://wiki.ubuntu.com/Bugs/Responses#Not%20described%20well response you can copy and paste it on the bug report (04:18:44 PM) pedro_: Another step into the Triage process is the: (04:19:08 PM) pedro_: * Assigning bugs to the proper package (04:19:25 PM) pedro_: the list of bugs without a package is a bit big as today there are around ~1850 only New bug reports without a package assigned to it, http://tinyurl.com/withoutapackage (04:19:50 PM) pedro_: Almost all the bugs on that list need to be assigned to a package (they're waiting you to assign them!) (04:20:25 PM) pedro_: this process is one of the easier tasks in the bug triage if you want to start doing triage you can probably start triaging them, want to know how to figure it out to which package assign the report? you can read the https://wiki.ubuntu.com/Bugs/FindRightPackage doc or ask on the #ubuntu-bugs channel (04:20:39 PM) pedro_: QUESTION: I'm glad you brought up debugging procedures. Having dealt with users of average computing expertise, do you find that the instructions on https://wiki.ubuntu.com/DebuggingProcedures are too complicated for them, causing them to abandon the bug report rather than following through. What are you thoughts on this and how ubuntu-bug/ apport can bring automation of the debugging process? (04:20:45 PM) pedro_: this is a really good questions (04:21:50 PM) pedro_: It's true we get a lot of reports from users, normal users, probably not all of them know a lot of computers (04:23:00 PM) pedro_: and probably they're not going to understand how to get send the logs of Xorg even with the instructions we provide (04:23:15 PM) pedro_: and that's ok (04:23:29 PM) pedro_: that's why now we have this awesome tool "ubuntu-bug" (04:23:52 PM) pedro_: and I really, really, really, really recommend you to use it for reports bugs in Ubuntu (04:24:04 PM) pedro_: it collects everything automatically and you don't need to worry about nothing (04:24:16 PM) pedro_: oh well you need internet connection ;-) (04:24:48 PM) pedro_: but yes please use the ubuntu-bug tool and also apport to send your crashes to us (04:25:28 PM) pedro_: Let's keep going (04:25:35 PM) pedro_: * Confirming bug reports by trying to reproduce them (04:26:23 PM) pedro_: basically if you found a bug report that you can reproduce and the status is New then mark it as Confirmed stating on a comment why you're doing this if the report lack of information then add it and important, please do not confirm your own bug reports (04:26:50 PM) pedro_: QUESTION: How can bug triagers use "ubuntu-bug" or another tool to have the reporter send in more information? (04:27:05 PM) pedro_: good question, for existing bug reports you can send more information with apport-collect (04:27:18 PM) pedro_: example: apport-collect 12345 (04:27:52 PM) pedro_: what the tool does, is to check the tasks on the bug report (12345) and run the apport hooks for that package (04:28:10 PM) pedro_: then it will attach all the info for that report, for example the Xorg.0.log, lspci, etc, etc (04:28:38 PM) pedro_: so if you're triaging a Xorg bug and it doesn't contain that info, ask the reporter to run that command ;-) (04:28:46 PM) pedro_: let's keep rolling (04:29:11 PM) pedro_: * Sending bugs to their upstream authors, when applicable (04:29:21 PM) pedro_: * Cross-referencing bugs from other distributions (04:30:20 PM) pedro_: those are really important tasks and as said previously, Jorge "Awesome" Castro is going to give a talk right after this one which is going to cover the Bug Upstream Workflow, if you're interested in that, stay here on the channel ;-) (04:30:44 PM) pedro_: so we're not going to cover that now (04:30:59 PM) pedro_: I've talked to you about some Bug Status already (04:31:11 PM) pedro_: you've heard about "New" and "Confirmed" (04:31:17 PM) Shriram: vow how long is the session , been running long time (04:31:34 PM) pedro_: Shriram: like two days! (04:31:51 PM) pedro_: They are 9 status for bug reports on Ubuntu they are: (04:32:01 PM) pedro_: New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Fix Committed, Fix Released and Won't Fix (04:32:11 PM) ***JManGt is away: Vengo al ratin... (04:32:24 PM) pedro_: don't be confused i know that some of you've been doing triage on Bugzilla for example and New means a totally different thing there (04:32:58 PM) pedro_: New: means that no one has triaged or confirmed the bug yet (for the bugzilla folks UNCONFIRMED) (04:33:24 PM) pedro_: Incomplete: means that the bug is missing some information for example a debugging backtrace of a crash or steps in order to trigger the bug (NEEDINFO on bz) (04:33:47 PM) Shriram: pedro_: vow, obviously with breaks right ? (04:33:49 PM) pedro_: Invalid: is set when the report doesn't have the adequate information to determine whether or not it's a bug, yes there's people reporting things like "a" and "e" on the summary or "test". (04:34:20 PM) pedro_: Confirmed: is almost self explanatory and we talked about it previously, someone else than the reporter have the same bug (04:34:39 PM) pedro_: remember, please, please please please do not confirm your own reports, a kitten die when you do that (04:35:14 PM) pedro_: Triaged: status is set by a member of the Ubuntu Bug Control team (will talk about it later) when they think that the bug has enough information for a developer to start working on fix the issue. (04:35:40 PM) pedro_: <komputes> pedro_: Dealing with Launchpad a lot in your daily bug managing tasks, you are in a key position in inproving Launchpad Bugs. Are there important changes/features you personally would like to see in upcoming revisions of Launchpad that you believe will help the bug squad. (04:36:05 PM) pedro_: well, one of the *key* things I'd really like to see is a better (working) duplicate search (04:36:20 PM) pedro_: often i face bugs with backtraces and there's no way to search for that on launchpad (04:37:06 PM) pedro_: so yes that's one of the things I'd *love* to see shortly on LP (04:37:14 PM) pedro_: <komputes> pedro_: you mean searching within attachments? (04:37:59 PM) pedro_: yes and no, you can either have a page with a big text box where you could paste the backtrace and lp could return to you a list of bugs that look similar to your backtrace (04:38:22 PM) pedro_: or yeah like a "duplicate" button next to the attachment, either case would work fine i think (04:38:24 PM) ***JManGt is back (gone 00:06:15) (04:38:39 PM) ***JManGt is away: Vengo al ratin... (04:38:41 PM) pedro_: but for example people report bugs with apport or they paste the backtrace on the same summary (04:39:00 PM) pedro_: for the second case would be good to have another tool as well ;-) (04:39:29 PM) pedro_: and you probably could use that for searching a phrase like "nautilus hangs on samba shares with blah version" (04:39:59 PM) pedro_: the Gnome Bugzilla has something like that and it really rocks I'd encourage you to test that ;-) (04:40:15 PM) pedro_: btw http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi? (04:40:27 PM) pedro_: try it later and let me know what you think ;-) (04:40:36 PM) pedro_: ok folks let's keep going (04:40:49 PM) pedro_: we have more status to talk about (04:41:07 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, If that developer committed the fix to a bzr branch the bug needs to be marked as Fix Committed (04:41:27 PM) pedro_: and when that fix get released (a fix was upload to an official Ubuntu repository) the status of the bug is changed to Fix Released (04:42:03 PM) pedro_: but please remember that this doesn't apply to the packages on the proposed repository, they stay on Fix Committed until they're available on the updates (04:42:24 PM) ***JManGt is back (gone 00:03:52) (04:42:49 PM) pedro_: * Won't Fix: the status is applied when the bug fix is too controversial or when the feature that someone requested is not going to be implemented (04:43:18 PM) pedro_: if you request something like "make rhythmbox shake when i say banshee" that is not going to happen (04:43:31 PM) pedro_: so that bug probably would be marked as WontFix (04:43:49 PM) pedro_: If you have been doing a lot and good work on the triage front you can apply for membership on the Ubuntu Bug Control Team (04:43:57 PM) Sealbhach: Normal user here. I often think of reporting bugs but worried about it being a duplicate and wasting everybody's time. Do you get fed up with all the duplicate bug reports? (04:44:06 PM) pedro_: which is a subset of the Ubuntu BugSquad and that membership allows you to change the Importance of bugs, set the "Triaged" and "Won't Fix" status and look at private bug reports (04:44:20 PM) pedro_: Sealbhach: ask on #ubuntu-classroom-chat ;-) (04:44:30 PM) Sealbhach: OK (04:44:34 PM) pedro_: The importances are 6: Undecided, Wishlist, Low, Medium, High and Critical and you can read more about them at: Undecided, Wishlist, Low, Medium, High and Critical (04:45:23 PM) pedro_: we don't have enough time so i'm not going to talk you about it, you can read the https://wiki.ubuntu.com/Bugs/Importance if have questions just ask us (04:45:42 PM) pedro_: If you don't know on where to start doing triage we've been collecting easy tasks for you at https://wiki.ubuntu.com/Bugs/EasyTasks the ones marked with green are the easiest to do and the one at red require more experience (04:45:47 PM) hggdh: the link pedro_ meant to give you all is https://wiki.ubuntu.com/Bugs/Status (04:46:31 PM) pedro_: yeah if you want to read more about status read the link hggdh just posted (04:46:44 PM) pedro_: Recently we have been discussed to do a Mentorship program for the people who wants to join the BugSquad (04:47:18 PM) pedro_: if you're looking for someone to help you out during your way trough the Ubuntu BugSquad please have a look at https://wiki.ubuntu.com/BugSquad/Mentors (04:47:47 PM) pedro_: People already on the Ubuntu Bug Control team and willing to be a Mentor can also add their name to that list (04:48:05 PM) pedro_: so find a person on the area you want to start working and contact they so you can start working together ;-) (04:48:38 PM) pedro_: we're going to discuss all this deeper during UDS to come out with a more detailed Mentorship program (04:49:04 PM) pedro_: Question: mentoring to join the bugsquad or the bug control team? (04:49:24 PM) pedro_: the idea is to have more and better qualified people on the bug control team :-) (04:49:52 PM) pedro_: One of the rocking activities on the Ubuntu World are the famous Hug Days (Bug Days) (04:50:34 PM) pedro_: why we call them hug days? well the idea is if you triage a bug you win a hug! (04:50:47 PM) pedro_: well virtual hug, if you're going to UDS we can hug you there as well (04:51:06 PM) pedro_: We celebrate hug days almost every Thursday in fact today we're running a hug day based on new bugs since the Jaunty release: https://wiki.ubuntu.com/UbuntuBugDay/20090430 (04:52:15 PM) pedro_: and it was just announced that the Kernel Team is going to celebrate hug days twice a month on Tuesdays IIRC (04:52:40 PM) pedro_: so if you're interested on the Kernel, stay tune to announcements on that front! (yeah subscribe to the ubuntu-bugsquad mailing list) (04:53:15 PM) pedro_: If you participate on a LoCo team... you can organize a Bug Jam! (04:54:19 PM) jcastro: 5 minute warning! (04:54:20 PM) pedro_: the idea is to get together with your LoCo team and start working on some of the bugs on Ubuntu (04:54:35 PM) pedro_: it could be bugs without a package, new bugs, incomplete reports, etc (04:54:51 PM) pedro_: if you look at https://wiki.ubuntu.com/Bugs/Events (04:55:29 PM) pedro_: you'll see a good list of teams there that were signed for the Ubuntu Global Bug Jam but some others for Bug Jams (04:55:51 PM) pedro_: the Berlin team for example is doing an amazing job on that front and they're doing 2 bugs jams a month (amazing) (04:56:15 PM) pedro_: so more information on how to run a bug jam? sure https://wiki.ubuntu.com/RunningBugJam (04:57:29 PM) pedro_: and again if you have doubts about anything, just talk too us trough the communications channels already described (04:57:48 PM) pedro_: and happy triaging everybody!