Ubuntu Wiki

Brian Murray Interview

Original file: http://people.ubuntu.com/~dholbach/brian-murray-interview.ogg

Linked from: https://wiki.ubuntu.com/RunningBugJam

Transcript:

I: And joining us today on the line is Brian Murray, known as the bug-master in the Ubuntu community. Brian how are you today?

B: I'm good, thanks for having me here.

I: Great, we're glad you can join us. Ummm, Brian, if you could first begin by telling us a little bit about yourself maybe like what exactly your role is in the Ubuntu community and how you got to be there?

B: Well, my role is to ensure that we have quality bug reports about the Ubuntu distribution. This involves gathering debugging material about specific packages, applications, and subsystems, and then making that information usable for bug reporters and bug triagers. We have a large community of bug triagers, known as BugSquad, and so we want to make it so they can learn about packages and subsystems and then engage in a dialog with bug reporters to gather that information so the bug is in a usable format for the developers to work on either fixing bugs or implementing a new feature in Ubuntu.

I: So how can... Can you give us an example of a bug reporter and a what, bug squasher, bug smasher? What's their role exactly? Are they a package maintainer or is this a separate person.

B: One analogy would be to technical support. So, somebody has reported that a certain feature of an application doesn't work. For the developer to recreate the bug, and stat working on that bug, it is possible that we would need certain log files to reproduce the bug, and also get information about the bug reporters environment. So, this is where the bug squad comes in. We hve written the various documentation about how to gather that information so that if the bug reporter didn't include that information in the report, the bug squad will help gather that information. Bugs are initially reported in a "New" status. There are about 9 different statuses. And one of the first things a developer would look at are the bugs in triage status.

I: Oh, okay, well, just curious, can you tell me what are the 9 statuses of a bug, since we use a bug tracking system or ticketing system at work -- and we only have 4.

B: Sure, initially a bug is reported "New." A bug can become incomplete in the sense that there is not enough information. A bug can become "Confirmed" where all that information has been gathered and someone has been able to recreate that bug. And then there is this access-controlled bug status state called "triage" where there is even a team at that state. There is "In Progress" when the bug is being worked on. Then there is "Committed" when the fix is there, but not yet downloadable. For example, there is a hyphen-proposed [e.g. hardy-proposed, etc.] where all the "Committed" bugs go. Then there's "fix released," where the fix is released to every Ubuntu user. Then theres the "Invalid" status where perhaps the bug reporter did not give enough information in a timely manner to get the bug confirmed, or if it was just a configuration problem it could get moved to "Invalid." We also have "Won't Fix" meaning that the particular fix will not be included in the piece of software. So that should be all nine.

I: Okay. very cool. Um, just a trivia question. What is the progress with bug #1?

B: In progress.

I: Oh, okay, cool. Just wanted to check on that. If you want to know what that is listeners, just head on over to Launchpad, and we'll include a link to that in our shownotes. So, how did you become the "bug-master," or how did you get to that state? Are you like a Canonical employee or what?

B: Yes I am an employee of Canonical. Canonical has a few employees working on bugs, bug triage, and other bug work apart from the distribution. Um, and I have been working for Canonical for about a year and a half now, and I started off as one of the two QA people and leading the Bug Squad and Bug Control teams.

I: Cool, so tell us then, I am an average joe, and I encounter a problem with Ubuntu or with one of the programs, how do I know it is a bug, and then, how can I report it? Can you tell us how one goes and reports a bug?

B: A bug can be identified when a program in Ubuntu does not work as advertised, or in the way you expected, or in the way you think it should. Um, I mean, an Ubuntu application isn't going to beat your dog, but perhaps a program could be improved by adding a new feature. That's a legitamate bug. So to recap, an application may not work the way it is advertised, behave like you expected, or have a certain feature you want, but those are three possible bug reports. So now for a bit about how to report a bug in Ubuntu. And then I think you asked about how to ask for how to file a bug report. Well, we use Launchpad for all our bug reports, however there is some functionality built into some applications in the Ubuntu distribution. For example, if you were to go into firefox and go to the "help" menu, you would see a "Report a problem" option, and what that will do is open an application called "apport" which will automatically gather bug data about the application and the system you are running. That report will automatically attached to the bug report you file in Launchpad. So since apport does all that work for you, that is the preferred method.

I: Okay, and is that fairly self explanatory then, to a novice user, its going to ask them for all the relevant information that you would want, so it pretty streamlines the process?

B: It'll automatically gather a lot of the information and then when you actually go to the report, it'll attach the attachments to your description of the bug report in Launchpad. When you reporting a bug in launchpad your asked for a title (or a summary) of the bug report and then also your presented with a dialog box to enter initial description of the bug report and also at the same time you can add attachments which would be supporting documentation for your bug report

I: Okay, cool. So I guess then basically anytime somebody finds a bug, should they just start reporting it? or is there anything they should do before they submit a bug report?

B: Ideally the bug reporter would do some due diligence and do some research to find out whether the bug has already been reported about the Ubuntu distribution. So for example if you have a bug with Firefox 3.0 it would be great if you could go and look and see if your particular bug has already been reported about Firefox and then add information, if you have some useful information to provide to that particular bug report, to the bug report, or you can subscribe to the bug report and then receive email updates as to the progress of the bug as developers are working on it.

I: Okay so..

B: Additionally...

I: Go ahead, sorry.

B: However there are a few bug reports about Firefox so it could be challenging to find the bug report. In the event that you can't find it and want to submit a new bug report. that's absolutely fine. and then one of the other responsibilities of the BugSqaud is to help find duplicates. so perhaps there is a BugSquad member who is really familiar with Firefox so they might have already heard of your bug report and then mark your bug as a duplicate of the one that was already in launchpad.

I: Okay, I was going to ask how you handle duplicates, whether you just merge them in or say it has already been reported. So if you do something like that, if you mark a bug as a duplicate, does the person who reported the duplicate copy get notifications for the original.

B: Yes, you become a subscriber of the original bug report and then they will get notifications about what is happening in the original bug report. and then that's it. if there's any conversation about the bug, that takes place in the original bug report.

I: Okay, excellent. So, tell us a little bit about, let's say I submit a bug, and I find a bug with, let's say your example, Firefox, now is the bug team going to try to fix a bug with Firefox; do they then, you know, submit an upstream patch or do they just notify Mozilla and take it from there, how does that work?

B: Firefox is an interesting example, we have a large patch set for that specific application, so it's possible that the bug exists in our release of Firefox and not upstream , so then an additional thing that the BugSquad would do is test the report with an upstream version of Firefox and see whether or not its possible that we create the bug with that version. in the event that it was, we would forward that bug to the developers of the software, and launchpad has the ability to watch an upstream bug report, so we can monitor the status of it and see what is happening there. however with a lot of applications our goal is for the package juts to be synced. So with a lot of applications we sync directly from Debian. So if a bug exists in the Ubuntu version of the package it also exists in the Debian one, in which case we would create that relationship between the bug reports.

I: Okay, so you're basically dependent on the Debian team fixing the package at that point then?

B: No, not at all, a lot of Ubuntu developers are also Debian developers. So it's possible that they would end up fixing the bug report upstream, and then the next time a sync was done of that package, then the fix would be pulled into Ubuntu.

I: Gotcha, okay. Alright. Now what if the problem is not with Firefox. You mentioned the "Help -> Report A Bug" tool. Is that something that you could still use fr non Firefox bugs or is there a different program for that? Is that a different bug reporting tool?

B: So lots of applications on the Ubuntu desktop have this Help -> Report a problem menu item. Gnome-terminal, for example, also has it. However this becomes an issue with some things like the kernel, you know there isn't a help menu for the kernel and there's not a help menu for xorg. So for reporting those bugs, apport also has a command line interface if you want to use that, where it would gather the same information we were talking about, the specific package version, what release of Ubuntu you're running, and add that to the bug report. Alternatively, you're absolutely welcome to file a bug report directly in Launchpad.

I: Okay and so is that a matter of you just go to launchpad.net and follow the prompts there to submit a bug, or is there any specific procedure; is it really obvious to a new user?

B: Yes, it's fairly obvious. You have to sign up for a user account, and then you would want to file a bug about the...Launchpad hosts a lot of projects, not just Ubuntu. So you would want to file a bug about the Ubuntu distribution. And then one dialog that sometimes becomes confusing is identifying the source package. So when your system boots up you are presented with an Ubuntu logo. And there's that grubber during the boot process. So with that application, how do you know what the package name for that is?

I: [Chuckles]

B: We have some documentation at wiki.ubuntu.com/FindRightPackage and that has information on how to determine what the package name is when your reporting a bug in Launchpad. And the particular application I was talking about is called usplash. But it also has information about what package to use for the kernel, what package to use for X, which is your display environment. And frequently we seem to get a lot of bug reports where the bug doesn't have a package. Currently we have about 3,000 of those bug reports outstanding. And those bug reports aren't looked at regularly. And they're definitely not looked at by the Firefox maintainer, they're not looked at by the X maintainer. So it's really critical that then you're reporting a bug about an application, that you include the source package name. And that is why it's particularly useful to go to that Help -> Report A Problem menu item. That way that information is gathered for you automatically.

:: 15:28