## page was renamed from MeetingLogs/OpenWeek BugsquadTeam2
== Ubuntu Open Week - The Ubuntu Bug Squad - Thu, Nov 30, 2006 ==
see also [[MeetingLogs/openweekedgy/BugsquadTeam|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.
}}}