BugsquadTeam2
Ubuntu Open Week - The Ubuntu Bug Squad - Thu, Nov 30, 2006
see also Tuesday Session.
05:00 elkbuntu Next up is Simon Law to recruit you all to the bug squad :) 05:02 sfllaw Good morning. 05:02 sfllaw Welcome to my talk about the Ubuntu BugSquad. 05:02 sfllaw ------------------------------------------------------- 05:03 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. 05:03 sfllaw The secret to this is huge community involvement. We have hundreds of people who help with packaging, translations, technical writing, and bug management. 05:03 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. 05:03 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. 05:03 sfllaw You can find our bug tracking system at https://launchpad.net/distros/ubuntu/+bugs 05:03 sfllaw Right now, it holds over 20000 open bug reports, spread across the entire distribution. That includes main, restricted, universe, and multiverse. 05:03 sfllaw That's a lot of bugs. The source of these reports can be found here: http://tinyurl.com/yf4hq9 05:03 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. 05:03 sfllaw :) 05:04 sfllaw To triage a bug report, you need to do a few things. 05:04 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. 05:04 sfllaw To start, we go to http://launchpad.net Click on "The Ubuntu distribution" 05:04 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. 05:04 sfllaw Click on 'Source Package "bash" in Ubuntu' to be taken to its package page. 05:04 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. 05:05 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. 05:05 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. 05:05 sfllaw You want to make sure that: 05:05 sfllaw Status = Unconfirmed only 05:05 sfllaw Importance = Undecided only 05:05 sfllaw Assignee = Nobody 05:05 LinuxBA !logs 05:05 ubotu Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs - See also !OpenWeek 05:05 sfllaw Click the "Search" button. 05:05 sfllaw You should end up at http://tinyurl.com/yawhpj which gives you a nice list of bugs to look at. 05:07 sfllaw My example bug went away. 05:07 sfllaw But we'll fix that. 05:07 sfllaw Dum de dum dum. 05:07 sfllaw Ta da! 05:07 sfllaw Reload guys. 05:07 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 05:07 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. 05:08 sfllaw Here's the minimum information for a complete bug report: 05:08 sfllaw 1. Version of the software. Is it in Dapper, Edgy, Feisty? What about a specific version number? 05:08 sfllaw 2. Steps to reproduce the bug. 05:08 sfllaw 3. What was expected to happen. 05:08 sfllaw 4. What actually happened. 05:08 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. 05:08 sfllaw Implicitly, we know the answers to 3 and 4, because Bash crashed unexpectedly. And the crash report has the version of bash buried inside (3.1-5ubuntu1). 05:08 sfllaw Still, we need to ask for reproduction steps. 05:08 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. 05:08 sfllaw There are some fields there: 05:09 sfllaw Package: this is the source package of the bug. Bash is correct for this one. 05:09 sfllaw Status: change this to Needs Info. This means other people won't try to triage this bug. 05:09 sfllaw Assigned to: Me. You're claiming responsibility for having a conversation with the reporter. 05:09 sfllaw Comment on this change: Here we should ask the reporter for more information. 05:09 sfllaw E-mail me about changes to this bug report: Yes. This will subscribe you to any new comments about this report. 05:09 sfllaw In the comment, we would ask for the version of Bash: 05:09 sfllaw "Hi Longer. Could you please describe the precise steps you performed to crash bash? Thanks." 05:09 sfllaw Click "Save Changes" and you're done. 05:09 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. 05:09 sfllaw We can now pass this on to the development team to fix. 05:09 sfllaw Click "bash (Ubuntu)" again and change: 05:09 sfllaw Status = Confirmed 05:09 sfllaw Assigned to = Nobody 05:09 sfllaw Click "Save Changes". 05:09 sfllaw That's it, you're done triaging this bug. 05:10 sfllaw daxelrod asks: Apport doesn't report the ubuntu release version? 05:10 sfllaw It does, actually. 05:10 sfllaw The DistroRelease field in an apport report should tell you what it is. 05:11 sfllaw For instance, in #57413, it tells you that this bug was in Ubuntu 6.10. 05:11 sfllaw Also, you can see the version of bash: "Package: bash 3.1-5ubuntu1" 05:11 sfllaw And the versions of all of its Dependencies. 05:12 sfllaw LjL asks: About "Version of the software" - should a reporter just state it (and the Ubuntu version) in the plaintext bug report, or should care be taken to actually use the Launchpad-native features for specifying versions (the usage of which, honestly, is not very clear to me)? 05:12 sfllaw The answer to this is that there are no Launchpad-native features for providing the version number. 05:12 sfllaw Often, it is good enough to know which Distribution it is. 05:13 sfllaw One of the reasons you want to know the version is so that you don't go hunting for a bug that doesn't exist in the most recent source package. 05:13 sfllaw Another reason is because if you notice a flood of bugs being filed against one package for a stable version, you know there's probably a crisis and you should tell someone. 05:14 sfllaw Jucato asks: In reporting a bug, how do we know which package in Launchpad's list a certain program belongs to? 05:15 sfllaw That requires a bit of good judgement. 05:15 sfllaw The https://wiki.ubuntu.com/Bugs/FindRightPackage wiki page can help with some strategies to find it. 05:16 sfllaw arualavi asks: what's the meaning of the word "triaging" pease? 05:17 sfllaw triaging is the process of sorting and allocating aid on the basis of need. 05:17 sfllaw It's been traditionally applied to medical treatment or food handouts. 05:17 sfllaw But here it applies to new bugs that come in. 05:18 arualavi sfllaw: thank you ;-) 05:18 sfllaw Phoenix7477 asks: How should a triage handle a problem where a bug is listed against an older version of, say bash? Check to see if its in the new one? If it is not reproducible in the new version, should the bug be cleared? 05:19 sfllaw In an older version of bash, you can check to see if it's in the new one. If it is, mention that this is the case in the description. 05:19 sfllaw If it's not in the new one, it should still be left open. 05:19 sfllaw If it's important enough, someone will issue a fix in the foo-updates archive. 05:19 sfllaw Or someone will backport the new one. 05:20 sfllaw Jucato asks: follow-up: isn't there a way to make reporting bugs a bit easier, for example in choosing which package the bug belongs to? I've compared Malone to bugs.kde.org, and while KDE's process is a bit longer (6 pages), it's also a bit less prone to error. 05:21 sfllaw Yes. We've recognized that Bugzilla has a nicer process for guiding people through filing bugs. 05:21 sfllaw I think it's a bit complicated, when much of this stuff can be automated. 05:21 sfllaw That's why https://blueprints.launchpad.net/distros/ubuntu/+spec/bug-reporting-tool exists, which we are implementing for Feisty. 05:21 Jucato nice 05:22 sfllaw Shall we move on? 05:22 sfllaw Let's say you encounter a bug report that isn't a bug at all. 05:22 sfllaw Perhaps it is a user asking for help on installing software. Like a request to be taught how to use synaptic. 05:22 sfllaw Or perhaps it is a user asking for a new feature to be implemented. 05:22 sfllaw You can distinguish between features and bugs this way: 05:22 sfllaw A feature request is a wish for new functionality that the program isn't expected to do. 05:22 sfllaw Whereas a bug is where the program fails in some way. It obviously should be doing something more correct. 05:22 sfllaw You can respond to these by: 05:22 sfllaw - Setting Status = Rejected 05:22 sfllaw - Writing them a nice note in the comment explaining why it was not a valid bug. 05:22 sfllaw You can get templates of these nice notes at https://wiki.ubuntu.com/Bugs/Responses 05:23 sfllaw But you are welcome to put in your own personal touches. Just remember to be friendly and polite, not terse. 05:23 sfllaw Being concise can be mistaken for being rude. 05:23 sfllaw LjL asks: Should anyone feel free to change a bug's status from "Unconfirmed" or "Needs info" to "Confirmed" (and similar), if they're convinced that the status of the bug has changed, or is it better etiquette to let the assignee (if any) make this sort of changes? 05:24 sfllaw You should feel free to change something to Needs Info, if you're going to claim responsibility. 05:24 sfllaw You can also change it to Confirmed if all the information is inside the bug. 05:24 sfllaw Rejected is also fine, if it's not a bug. 05:25 sfllaw As is Fix Released, if the _reporter_ says the bug has been fixed by a newer version. 05:25 sfllaw If there's an assignee, you shouldn't go mucking about the Status too much. 05:25 sfllaw Some of the other statuses have different meanings for different teams. 05:26 sfllaw davmor2 asks: After your last talk I have witnessed the amount of bugs, how important is it to get the initial triage out of the way? 05:26 sfllaw It's fairly important that we try to clear out the queue of untriaged bugs. 05:26 sfllaw If they're untriaged, nobody has looked at them. 05:26 sfllaw And if nobody has looked at them, nobody will fix them. 05:26 sfllaw :( 05:27 sfllaw daxelrod asks: While the FindRightPackage wiki page helps, is there any list that maps project names to descriptions? (For example: LiveCD Installer <-> Ubiquity) 05:27 sfllaw Not to my knowledge. 05:27 sfllaw If you would like to help, you can add a section that puts this stuff in. 05:27 sfllaw Like the fact that the LiveCD is casper. 05:27 sfllaw It is a Wiki. :) 05:28 sfllaw rmjb asks: is it bad form to assign yourself to a bug for which you are not the package maintainer? 05:28 sfllaw It's perfectly find to assign yourself to a bug no matter who maintains it. 05:29 sfllaw Assignment has a specific meaning. It means "I will take responsibility for shepherding this bug." 05:29 sfllaw That's why, when triaging, you assign yourself to the bug while you're waiting for an answer. 05:29 sfllaw Then you can search for a list of bugs you're assigned to and follow up on them. 05:29 sfllaw When you are done triaging, you assign to Nobody. 05:29 sfllaw Someone else will take responsibility after that. 05:30 sfllaw davmor2 asks: I noticed too that their is a section for importance who sets this? 05:30 sfllaw People on the Ubuntu QA team, the Masters of the Universe, and Core Developers can set this. 05:31 sfllaw Importance has very specific meanings, so you have to go through simple training to join. 05:31 sfllaw It's pretty easy, see https://wiki.ubuntu.com/Bugs/Importance, but beyond the scope of this talk. 05:32 sfllaw Jucato asks: what's the difference between Fix Committed and Fix Released? 05:33 sfllaw Generally, Fix Released means that the fix has been properly sent out to the general public. In Ubuntu, we use it to mean that it's been sent to a default archive. Like feisty or edgy-updates. 05:33 sfllaw Fix Committed means that a fix is available somewhere. In Ubuntu, this means someone has a package in their own personal archive, or they uploaded it to edgy-proposed. 05:34 sfllaw Yawner asks: After looking at a few comments on bugs, its fairly obvious that some are more important than others, as someone not on the QA Team, how do I know which bug is important and which is not? If I feel that its important what exactly do I do about it? 05:34 sfllaw Learn about Importances and then ask dholbach or me to add you to the Ubuntu QA team. 05:34 sfllaw We'll ask you a few simple questions and then you'll have access. 05:35 sfllaw davmor2 asks: if you get in over your head with a bug where can you turn? 05:35 sfllaw Other members of the Bug Squad can help you. You can find someone online all the time. 05:36 sfllaw siretart asks: in what cases do you think it makes sense to assign a bug to a team? What semantic does this have? 05:36 sfllaw Each team typically has its own policy on what it means to assign something to it. 05:36 sfllaw You probably shouldn't assign something to a team unless you're following that policy. 05:37 sfllaw There is documentation on the Ubuntu Wiki that will tell you when it's proper to assign or subscribe a particular team to a bug. 05:38 sfllaw davmor2 asks: if you find a bug that say allows anyone to change network setting (without asking for admin password) how can you get it prioritised? 05:38 sfllaw Find someone who has the power to change this online. There are a lot of us, actually. 05:39 sfllaw Generally, that should be filed as a security bug, so you won't bump into it. 05:39 sfllaw But try private messaging dholbach or me, if it isn't one. 05:39 sfllaw We'll set it to Security and give you a bug. 05:40 sfllaw LjL asks: Sometimes you experience problems that you can conceivably suppose to be due to bugs - however, you are not able to track the problem down to a given package, or reproduce it reliably. Normally, I feel that in these situations, a bug report would be useless or, even worse, distracting; however, there might still be some value in reporting the problem "somewhere", so what would you recommend? A forum post, a Launchpad support 05:40 sfllaw If you can't reproduce it reliably, a support request is probably your best bet. 05:41 sfllaw Yawner asks: If a bug contains a crash report, should you ask for a backtrace? Can you clarify the difference between the two? 05:41 sfllaw The crash reports contains a backtrace within. The difference is that the crash report is more complete. 05:41 sfllaw GNOME's bug buddy provides a bit of extra metadata. 05:41 sfllaw Apport provides a lot of Ubuntu specific metadata. 05:42 sfllaw OK. Done with this batch of questions. On we go. 05:42 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. 05:42 sfllaw For instance, let's look at the Totem's list of bugs: https://launchpad.net/distros/ubuntu/+source/totem/+bugs 05:42 sfllaw There's a bug about screen blanking while watching movies, http://launchpad.net/bugs/66257 05:42 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 05:42 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. 05:42 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. 05:42 sfllaw You can find new bugs by looking at the big list of untriaged bugs, that I mentioned before. 05:42 sfllaw Or you can join #ubuntu-bugs and listen as Ubugtu rattles off new bugs every few minutes. 05:42 sfllaw It says things like this: 05:42 sfllaw New bug: #73643 in gaim (main) "Gaim crashes while getting roomlist" [Undecided,Unconfirmed] http://launchpad.net/bugs/73643 05:43 sfllaw This tells you that a new bug has been filed for the gaim source package. 05:43 sfllaw Gaim lives in main. 05:43 sfllaw And it provides a description of what's wrong. 05:43 sfllaw Plus a handy URL to the bug. 05:43 sfllaw The description of a bug is mutable, so that you can summarize the discussion held in the comments. 05:43 sfllaw This is really useful because difficult bugs may have pages and pages of comments. 05:43 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. 05:43 sfllaw You should also make sure the Summary is something useful, so people browsing for duplicates can find a relevant bug easily. 05:43 sfllaw Bad descriptions are: "Program crashes." 05:43 sfllaw Good descriptions are: "Program crashes with 'Error 12: Can't find my brain on line 382.'" 05:43 sfllaw A good description is easily searchable using keywords people would think of. 05:44 sfllaw And error messages are good because they are often unique to the problem. 05:44 sfllaw Click "Change" after updating the text. 05:45 sfllaw Ubuntu bugs can be tied to upstream bugs. They can also be tied to bugs in other distributions. 05:45 sfllaw One example is bug 27810: http://launchpad.net/bugs/27810 05:45 sfllaw If you look at the task table, you'll see three different lines. 05:45 sfllaw libaio (Ubuntu) 05:45 sfllaw upstart (Ubuntu) 05:45 sfllaw libaio (Debian) 05:45 sfllaw So the first two have to do with Ubuntu packages. 05:45 sfllaw And the third has to do with Debian ones. 05:45 sfllaw If I were going through this bug doing triage right now, I'd do the following things. 05:45 sfllaw - Realize that it has nothing to do with upstart, and reject it. 05:45 sfllaw To do this, I click on the upstart (Ubuntu) task and set its Status to Rejected. 05:46 sfllaw - Notice that Fabio claims that this isn't a problem in Ubuntu because the brokenness was never imported. 05:46 sfllaw - Test to make sure I cannot reproduce the problem. 05:46 sfllaw If everything works properly, I set libaio (Ubuntu)'s Status to Rejected. 05:46 sfllaw In order to add upstream tasks, you will note two links under the task table: 05:46 sfllaw "Also affects: +Upstream... +Distribution..." 05:46 sfllaw If a bug affects another distribution like Fedora, Guadalinux, or Debian, with its own packages, use the +Distribution link. 05:46 sfllaw If a bug is caused by an upstream program's misbehaviour and is not a packaging bug, use the +Upstream link. 05:46 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. 05:47 sfllaw But often, the bug will already exist upstream, so you don't want to file a duplicate there. Just paste in that bug's URL in to our bug tracker. 05:47 sfllaw Every day, the status of this bug will be updated with the upstream's status. 05:47 sfllaw Plus, you can search for bugs which have been fixed by upstream. 05:47 sfllaw Now that I've got you interested, you may be asking "sfllaw: How can I join the BugSquad?" 05:47 sfllaw You don't have to have any serious experience before applying. You can start in BugSquad right now. 05:48 sfllaw Acceptance is automatic and we'd love to teach you the ropes. 05:48 sfllaw You can join by: 05:48 sfllaw - Joining the #ubuntu-bugs channel 05:48 sfllaw - Getting a Launchpad account 05:48 sfllaw - Applying for membership at https://launchpad.net/people/bugsquad 05:48 sfllaw For more information, please see https://wiki.ubuntu.com/HelpingWithBugs which describes how to help with bugs and how to participate in the BugSquad. 05:48 sfllaw We hang out in the #ubuntu-bugs IRC channel on irc.freenode.net. 05:48 sfllaw You can find help and encouragement (and hugs) there all the time. 05:49 sfllaw Finally, I want to point out that we have an UbuntuHugDay scheduled for next Wednesday. If you want to start helping with bugs, that would be a great time to pitch in. 05:49 sfllaw Thanks everybody! 05:49 sfllaw I've got eleven minutes for questions. 05:49 sfllaw daxelrod asks: Bug hugs? 05:49 sfllaw So this is one of the things we do to recognize when people have done good work. 05:50 sfllaw We give away virtual hugs when you've finished something. 05:50 sfllaw If you ever meet dholbach or me in real life, we're pretty happy to give you a real hug too. 05:50 sfllaw Hugging is a nice way to put a smile on someone's face. I highly recommend giving away free hugs. 05:51 sfllaw jrib asks: Can a bug have more than one assignee? If not, is it just because this will cause confusion? 05:51 sfllaw It doesn't really make sense to have more than one "person" responsible for a bug. 05:51 sfllaw If you want to keep track of a bug, you can subscribe to it. 05:51 sfllaw There can be an unlimited number of subscribers. 05:52 sfllaw Jucato asks: There's a particular situation regarding KDE bugs. KDE people want KDE bugs reported upstream rather than in Launchpad. does this present a problem for users and the bug squad? 05:52 sfllaw There is little we can do to prevent people from filing bugs in Ubuntu's bug tracker. And we don't want to discourage them. 05:52 sfllaw For instance, we could have introduced the bug ourselves with a patch. 05:52 sfllaw We are happy to forward bugs upstream so that KDE people can fix them. 05:52 sfllaw And link them in with our bug tracker, as I described above. 05:53 sfllaw Having it in Launchpad means Ubuntu developers will know about the problem and can find out about the fix when KDE releases it. 05:54 sfllaw Yawner asks: I have just opened a bug report for Skype, to my knowledge this is not within the Ubuntu Repositories? Do I just forward this bug upstream to Skype? Or reject it? 05:54 sfllaw So the answer to this is two-part: 05:55 sfllaw If it's a problem with Ubuntu that prevents a third-party package from working, that would be a bug. 05:55 sfllaw If it's the third-party package that's broken, you will want to Reject the bug and ask the reporter to talk with the authors. 05:55 Yawner hmm.. ok , thanks 05:55 sfllaw So as an example of the first problem, if we broke glibc by accident, then that would be our bug. 05:56 sfllaw The chances of this happening are pretty low, though. 05:56 sfllaw Jucato asks: well, they say that they don't get informed of the KDE bugs that are filed in Launchpad or that they don't want to keep track of 2 bugtrackers. who forwards them upstream, when and how are they forwarded, and how do you know which ones to forward? 05:57 sfllaw That is a fair statement, but there is nothing we can do to prevent users from filing KDE bugs into Launchpad. 05:57 sfllaw And Kubuntu is often the first experience people have with KDE. 05:57 sfllaw Even if they don't know what KDE is. 05:57 sfllaw The BugSquad is the group that does much of the forwarding. 05:58 sfllaw If you are interested in KDE packages, I hope that you will start triaging there. 05:58 sfllaw And become a local expert about various KDE bugs. 05:59 sfllaw All right, our time is up for this session. 05:59 sfllaw Thank you all for attending. 05:59 sfllaw I will field further questions in #ubuntu-bugs.
MeetingLogs/openweekedgy/BugsquadTeam2 (last edited 2008-08-06 16:17:58 by localhost)