BugsquadTeam
Ubuntu Open Week - The Ubuntu Bug Sqad - Tue, Nov 28, 2006
see also Thursday Session.
09:05 sfllaw Good afternoon. 09:06 sfllaw Welcome to my talk about the Ubuntu BugSquad. 09:06 sfllaw For the purposes of clarity, please limit discussions to #ubuntu-classroom-chat. If you want to ask a question, just write "sfllaw: I have a question about..." in #ubuntu-classroom-chat and I'll answer it at the approriate juncture. 09:06 sfllaw Thanks! 09:06 sfllaw --------------------------------------- 09:06 sfllaw Ubuntu is one of the most popular GNU/Linux distributions out there. And it also has one of the smallest development teams for its size. 09:06 sfllaw The secret to this is huge community involvement. We have hundreds of people who help with packaging, translations, technical writing, and bug management. 09:07 sfllaw And boy do we have a lot of bugs. About 300 to 400 new bug reports get filed every day from users, from stable releases like Dapper to bleeding edge stuff from Feisty. 09:07 sfllaw The first people to look at these reports are the BugSquad. We do a very important task, drinking from this firehose. And that's to make sure that the reports that remain in the bug tracking system are useful. 09:07 sfllaw You can find our bug tracking system at https://launchpad.net/distros/ubuntu/+bugs 09:07 sfllaw Right now, it holds over 20000 open bug reports, spread across the entire distribution. That includes main, restricted, universe, and multiverse. 09:07 sfllaw That's a lot of bugs. The source of these reports can be found here: http://tinyurl.com/yf4hq9 09:07 sfllaw These are untriaged reports: ones which have never had a human eye look at them. It's likely that they are missing information, duplicate another report, are filed against the wrong package, etc. Or, if you're lucky, they're perfect. 09:07 sfllaw :) 09:08 sfllaw To triage a bug report, you need to do a few things. 09:08 sfllaw First you have to determine if it's actually a bug. The easiest ones have crash reports in them. Let's go find one. 09:08 sfllaw To start, we go to http://launchpad.net Click on "The Ubuntu distribution" 09:08 sfllaw In the search box, let's look for a popular package. Bash is a good one to try, so let's ask for that. 09:09 sfllaw Click on 'Source Package "bash" in Ubuntu' to be taken to its package page. 09:09 sfllaw This shows you Bash within the context of the Ubuntu distribution. Bash also has another page, a product page, which we won't look at right now. 09:09 sfllaw In the left sidebar, you should see a "Bugs" link. Click on that and you'll be taken to the bug tracker. This will list all the bugs inside bash right now. 09:09 sfllaw There are quite a few untriaged bugs, but they are intermixed with triaged ones. Let's narrow down our search to only show untriaged ones. Start by clicking the "Advanced search" link. 09:09 sfllaw You want to make sure that: 09:09 sfllaw Status = Unconfirmed only 09:09 sfllaw Importance = Undecided only 09:09 sfllaw Assignee = Nobody 09:10 sfllaw Click the "Search" button. 09:10 sfllaw You should end up at http://tinyurl.com/yawhpj which gives you a nice list of bugs to look at. 09:10 sfllaw Bug 57413 looks like a promising crash. Click on its description and it will open up. You can also get to this bug by going to http://launchpad.net/bugs/57413 09:10 sfllaw You see that the bug reporter has included his crash dump, which was caught by apport, our automated crash profiler. But Longer hasn't really given us enough information to solve the problem. 09:11 sfllaw Here's the minimum information for a complete bug report: 09:11 sfllaw 1. Version of the software. Is it in Dapper, Edgy, Feisty? What about a specific version number? 09:11 sfllaw 2. Steps to reproduce the bug. 09:11 sfllaw 3. What was expected to happen. 09:11 sfllaw 4. What actually happened. 09:11 sfllaw Since this bug is incomplete, we'll want to ask for more information. You do that by taking responsibility for the bug and having a conversation with the reporter. 09:11 sfllaw Implicitly, we know the answers to 3 and 4, because Bash crashed unexpectedly. 09:12 sfllaw And the crash report has the version of bash buried inside (3.1-5ubuntu1). 09:12 sfllaw Still, we need to ask for reproduction steps. 09:12 sfllaw If you're logged in, you can click on the "bash (Ubuntu)" task table up near the top. This allows you to modify the state of the bug. 09:12 sfllaw There are some fields there: 09:12 sfllaw Package: this is the source package of the bug. Bash is correct for this one. 09:12 sfllaw Status: change this to Needs Info. This means other people won't try to triage this bug. 09:12 sfllaw Assigned to: Me. You're claiming responsibility for having a conversation with the reporter. 09:12 sfllaw Comment on this change: Here we should ask the reporter for more information. 09:12 sfllaw E-mail me about changes to this bug report: Yes. This will subscribe you to any new comments about this report. 09:13 sfllaw shawarma points out that apport, which generated this crash dump, wasn't in Dapper. 09:13 sfllaw So it must be an Edgy bug. 09:13 sfllaw But apport also tells you the difference between an Edgy bug and a Feisty bug. 09:14 sfllaw at2000 asks: who should modify these fields? 09:14 pitti (in the DistroRelease: field) 09:14 sfllaw You, as the triager, get to set these fields. 09:15 at2000 so someone officially in the BugSqad team? 09:15 sfllaw Yes. In fact, you get to set them before you join BugSquad. 09:15 sfllaw Although it's good form to be know how to change them properly before you start doing so. :) 09:16 sfllaw But that's why you're here! 09:16 sfllaw So... 09:16 sfllaw You've set the proper meta-data on the bug and have taken responsibility. 09:16 sfllaw In the comment, we would ask for the version of Bash: 09:16 sfllaw "Hi Longer. Could you please describe the precise steps you performed to crash bash? Thanks." 09:16 sfllaw Click "Save Changes" and you're done. 09:16 sfllaw When you get an e-mail from Longer responding to your question with the appropriate steps, the bug can be considered complete. You've got information on how to reproduce it and there's even a handy log file for a developer to look at. 09:17 sfllaw We can now pass this on to the development team to fix. 09:17 sfllaw Click "bash (Ubuntu)" again and change: 09:17 sfllaw Status = Confirmed 09:17 sfllaw Assigned to = Nobody 09:17 sfllaw Click "Save Changes". 09:18 sfllaw rulus asks: where ends the task of the Bug Squad team? here? 09:18 sfllaw The BugSquad team actually works on all parts of bugs. 09:18 sfllaw However, the job of a triager ends here. 09:18 sfllaw Basically, it's like the first response you get at a hospital. 09:19 sfllaw You want to manage the huge flow of incoming bugs so that people fixing them aren't overwhelmed. 09:20 sfllaw La_PaRCa asks: is it part of the triager work to mark duplicates? 09:20 sfllaw Yes, it is. 09:20 sfllaw I'm going to get to that later. 09:20 sfllaw Let's say you encounter a bug report that isn't a bug at all. 09:21 sfllaw Perhaps it is a user asking for help on installing software. Like a request to be taught how to use synaptic. 09:21 sfllaw Or perhaps it is a user asking for a new feature to be implemented. 09:22 sfllaw You can distinguish between features and bugs this way. 09:22 sfllaw A feature request is a wish for new functionality that the program isn't expected to do. 09:23 sfllaw Whereas a bug is where the program fails in some way. It obviously should be doing something more correct. 09:23 sfllaw You can respond to these by: 09:23 sfllaw Setting Status = Rejected 09:23 sfllaw And writing them a nice note in the comment explaining why it was not a valid bug. 09:24 sfllaw You can get templates of these nice notes at https://wiki.ubuntu.com/Bugs/Responses 09:24 sfllaw But you are welcome to put in your own personal touches. Just remember to be friendly and polite, not terse. 09:24 sfllaw Smiffeh asks: should you build up some serious experience with triaging before you apply to join the bugsquad? 09:25 sfllaw No, you don't have to. You can start in BugSquad right now. 09:25 sfllaw Acceptance is automatic and we'd love to teach you the ropes. 09:25 sfllaw Bourlotieris asks: I have a question about how do you join the Bugsquad team 09:26 sfllaw You can join by: 09:26 sfllaw - Joining the #ubuntu-bugs channel 09:26 sfllaw - Getting a Launchpad account 09:26 sfllaw - Applying to enter at https://launchpad.net/people/bugsquad 09:27 sfllaw Grishkin asks: Is there a special ubuntu team for making new bugs? 09:27 sfllaw In order to report a bug, you don't need anything but a Launchpad account. 09:27 sfllaw See https://help.ubuntu.com/community/ReportingBugs for how to file a bug report 09:28 sfllaw davmor2 asks: do you need any technical or programing skills to join the bug squad 09:28 sfllaw It helps, but you don't have to. 09:29 sfllaw Even if you understand nothing about computers, there are some bugs that you can help out with. 09:29 sfllaw They may be more difficult to find, but we are working on making it simpler. 09:29 sfllaw For instance, you can verify that "yes, there is a typo in this documentation". 09:29 sfllaw And you can try to reproduce bugs. 09:29 sfllaw And gather debugging information that users haven't yet provided. 09:30 sfllaw Another way to help out if you don't have a lot of technical knowledge, but enough to understand how a program _should_ work, is to look for duplicates. 09:30 davmor2 sfllaw: that was where I was assuming you may need some skills knowing what to ask for 09:31 sfllaw In order to gather debugging information, you will want to read the http://wiki.ubuntu.com/DebugginProcedures page. 09:31 sfllaw It describes various procedures for various packages. 09:31 sfllaw We add documentation to that all the time. 09:31 sfllaw And we'd love it if other people helped add to it as well. 09:31 rulus it's https://wiki.ubuntu.com/DebuggingProcedures 09:32 sfllaw Curse my poor speeling. 09:32 sfllaw Moving on... 09:32 sfllaw A large class of reports are duplicates. These are filed by people who did not look or could not find a bug report identical to their problem. So they filed a new one. But looking through the bug tracking system, we can spot quite a few if we take some time. 09:32 sfllaw For instance, let's look at the Totem's list of bugs: https://launchpad.net/distros/ubuntu/+source/totem/+bugs 09:32 sfllaw There's a bug about screen blanking while watching movies, http://launchpad.net/bugs/66257 09:32 sfllaw It has one bug marked as duplicate. You can find a list of duplicates in the left sidebar. That one is http://launchpad.net/bugs/73029 09:33 sfllaw If someone filed a new bug that was exactly the same as this one, you could click on the "Mark as Duplicate" link in the left sidebar, and enter "66257" as the bug number. 09:33 sfllaw You can find new bugs by looking at the big list of untriaged bugs. 09:33 sfllaw Or you can join #ubuntu-bugs and listen as Ubugtu rattles off new bugs every few minutes. 09:33 sfllaw It says things like this: 09:34 sfllaw New bug: #73643 in gaim (main) "Gaim crashes while getting roomlist" [Undecided,Unconfirmed] http://launchpad.net/bugs/73643 09:34 sfllaw This tells you that a new bug has been filed for the gaim source package. 09:34 sfllaw Gaim lives in main. 09:34 sfllaw And provides a description of what's wrong. 09:34 sfllaw Plus a handy URL to the bug. 09:35 sfllaw samge1 asks: should trivial bugs (like a typo) be submitted as a bug or is it better fix them right away somehow (like a new suggestion for a translation)? 09:35 sfllaw It is best to file a bug report and point to a fix. 09:36 sfllaw This fix could be a new translation in Rosetta, or a patch attached to the bug report. 09:36 sfllaw This way, your fix doesn't get lost if it is a priority. 09:36 sfllaw If you are a developer, you are encouraged to use bugs to manage your fixes, even if you can uploda packages into Ubuntu. 09:36 sfllaw That way, you don't forget what's on your TODO list. 09:38 sfllaw finalbeta asks: What bugs should we report, I've reported hardware bugs (none got fixed), small software bugs (none get fixed), I've reported +-30 bugs in the last few months and only one crasher got fixed. Yet it will take 6 months before the fix will show up (in the next release). What bugs are the ubuntu people capable of handling?, should we just go upstream whenever possible? In short I mean, I should not bother reporting fglrx / a 09:38 sfllaw It is worth reporting bugs both to Ubuntu and to upstream. 09:38 sfllaw In fact, our bug tracking system has the capability to track upstream bugs. 09:39 sfllaw Ubuntu developers don't have a lot of resources, so we prefer to let upstream authors fix bugs unless they are critical. 09:39 sfllaw But we use the bug tracking system to monitor upstream bugs. If an upstream has fixed something major, we will often backport that fix. 09:40 sfllaw The goal of a triager is to reduce the clutter in the bug tracking system. 09:40 sfllaw You shouldn't be closing old bugs, as they might still be useful and relevant. 09:40 sfllaw But new bugs coming in should be examined for duplicates. 09:41 sfllaw This reduces the clutter in the bug tracking system. You want to choose the definitive bug with the most complete information, and make all the other duplicates refer to it. If information is scattered around, you can edit the description of the definitive bug. 09:41 sfllaw The description of a bug is mutable, so that you can summarize the discussion held in the comments. 09:41 sfllaw This is really useful because difficult bugs may have pages and pages of comments. 09:42 sfllaw Any bug can have its description edited, and a good summary saves people a lot of time sifting through the conversation. 09:42 sfllaw To change the description, click the "Edit Description/Tags" link in the sidebar. Try to clean up the description with a good summary of: Version, Reproduction steps, Expected result, Actual result, and a Diagnosis of the problem. 09:42 sfllaw You should also make sure the Summary is something useful, so people browsing for duplicates can find a relevant bug easily. 09:42 sfllaw Bad descriptions are: "Program crashes." 09:42 sfllaw Good descriptions are: "Program crashes with 'Error 12: Can't find my brain on line 382.'" 09:42 sfllaw A good description is easily searchable using keywords people would think of. 09:43 sfllaw And error messages are good because they are often unique to the problem. 09:43 sfllaw Click "Change" after updating the text. 09:43 sfllaw a7p asks: what about #27810 - should this one be closed? Who does it if it should be done? 09:44 sfllaw This is a good example of how Ubuntu bugs can be tied to upstream bugs. 09:44 sfllaw If you look at the task table, you'll see three different lines. 09:45 sfllaw libaio (Ubuntu) 09:45 sfllaw upstart (Ubuntu) 09:45 sfllaw libaio (Debian) 09:45 sfllaw So the first two have to do with Ubuntu packages. 09:45 sfllaw And the third has to do with Debian ones. 09:45 sfllaw If I were going through this bug doing triage right now, I'd do the following things. 09:45 sfllaw - Realize that it has nothing to do with upstart, and reject it. 09:46 sfllaw To do this, I click on the upstart (Ubuntu) task and set its status to Rejected. 09:46 sfllaw Like so. 09:47 sfllaw - Notice that Fabio claims that this isn't a problem in Ubuntu because the brokenness was never imported. 09:47 sfllaw - Test to make sure I cannot reproduce the problem. 09:47 sfllaw If everything works properly, I set libaio (Ubuntu)'s status to Rejected. 09:48 sfllaw In order to add upstream tasks, you will note two links under the task table: 09:48 sfllaw "Also affects: +Upstream... +Distribution..." 09:48 sfllaw If a bug affects another distribution like Fedora, Guadalinux, or Debian, with its own packages, use the +Distribution link. 09:49 sfllaw If a bug is caused by an upstream program's misbehaviour and is not a packaging bug, use the +Upstream link. 09:50 sfllaw You will have to file the bug in the other bug tracker, but then you can paste that bug's URL in to the "Request fix in a..." page, which will link the bugs together. 09:50 sfllaw Every day, the status of this bug will be updated with the upstream's status. 09:50 sfllaw Plus, you can search for bugs which have been fixed by upstream. 09:50 sfllaw davmor2 asks: What is your description of security? would it be the root password problem a while ago 09:51 sfllaw A security bug is one that allows local or remote users to access data or privileges that they shouldn't normally be able to. 09:51 sfllaw This definition is a bit flexible and up the discretion of the security team. 09:51 pitti breezy's user password exposure definitively falls into this category 09:51 sfllaw If you file a security bug, only the people subscribed to it will be able to see it. 09:52 sfllaw rulus asks: how do you know it also affexts upstream? 09:52 pitti sfllaw's definition is pretty good; I'd extend it to 'or allows a local/remote user to bring down a service' 09:52 keescook the wiki page SecurityUpdateProcedures has some examples of what can qualify, too. 09:53 sfllaw It's easy to tell whether a bug is caused by us. 09:54 sfllaw if a package doesn't install, the description is incorrect, or something doesn't show up in a menu, then it's probably Ubuntu's fault. 09:54 sfllaw If a program crashes or misbehaves, it's probably an upstream problem. Especially if Google tells you that people using other distributions have the same problem. 09:55 sfllaw It is usually a good idea to Google for your bug to see if: 09:55 sfllaw - You can find other people with your problem. Often, these things will show up on newsgroups or forums (like the Ubuntu Forums) 09:55 sfllaw - You can find a bug in our bug tracking system already. 09:56 sfllaw - You can find a bug in someone else's bug tracking system (like Debian, Fedora, OpenSuSE, etc.) 09:56 sfllaw davmor2 asks: does this mean you need to be running bugzilla too in order to cross reference? 09:56 sfllaw You don't have to sign up for other people's Bugzilla if you don't want to. 09:56 sfllaw You can concentrate on whatever packages you like. 09:57 sfllaw But if you want to pitch in for a few days to help with Firefox bugs, you should probably sign up for the Firefox Bugzilla, so you can report bugs to them. 09:57 sfllaw It makes a lot of sense to concentrate on a set of packages. You can quickly become a local expert in some software. 09:58 sfllaw davmor2 asks: I have reported a lot of bugs which have been marked as duplicates due to me not being able to find anything similar is there a way to better search for a bug? 09:58 davmor2 sfllaw: I meant more to cross reference an ubuntu bug with a redhat bug 09:59 sfllaw To cross-reference with Red Hat, you should have a Red Hat bugzilla account to file bugs into their system. 09:59 sfllaw If the bug already exists, linking them together is free. 09:59 sfllaw But to be polite, you should comment in the Fedora bug with the URL to the Ubuntu one. 09:59 sfllaw That way, our distributions can work together to fix things. 09:59 sfllaw For your other question about duplicates... 09:59 rasman I had a problem with a new ATI card, how would I report a bug like that? How would it be addressed? 10:00 davmor2 makes sense more devs that way 10:00 sfllaw I've found the best way is to use Google. 10:01 sfllaw But to be sure, I often browse all open bugs for a particular package and look for potential descriptions to match. 10:01 sfllaw If you spend lots of time on a package, you will remember things that are similar. 10:01 sfllaw Sadly, search in Launchpad is not as good as it could be. 10:01 sfllaw We're running short on time. 10:01 sfllaw For more information, please see https://wiki.ubuntu.com/HelpingWithBugs which describes how to help with bugs and how to join the BugSquad. 10:01 sfllaw We hang out in the #ubuntu-bugs IRC channel on irc.freenode.net. 10:01 sfllaw You can find help and encouragement (and hugs) there all the time. 10:01 sfllaw Finally, I want to point out that we have an *UbuntuHugDay* scheduled for tomorrow. If you want to start helping with bugs, that would be a great time to pitch in. 10:02 sfllaw https://wiki.ubuntu.com/UbuntuHugDay 10:02 sfllaw Thanks everybody! 10:02 sfllaw We're out of time so I'll field questions in #ubuntu-bugs.
MeetingLogs/openweekedgy/BugsquadTeam (last edited 2008-08-06 16:19:06 by localhost)