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)