Bryce Harrington
Launchpad: ~bryceharrington
Usual location: Orgeon, USA
Role: Ubuntu X.org maintainer, employed by Canonical
Edited Notes
Bryce maintains the X.org stack in Ubuntu: he packages X.org components, fixes packaging bugs, triages bugs and works on documentation.
Bryce mostly navigates Launchpad using bookmarks.
Handling incoming bugs
Most people who file X.org-related bugs do not know which package to report the bug against. Bryce recommends that people file the bug against the X.org package and then he moves it to the correct package. So, the X.org package bug list is his incoming bug queue.
When triaging bugs, he usually looks for which video driver the person is using and move the bug to the package for that video driver. As he has an apport hook, many bug reports do have the right files attached but there are still some people who file bugs directly but don't attach the files he needs.
When someone has provided the right info -- i.e. the log file -- it's easy to see what driver they're using and so move the bug to the right package. So, Bryce has a launchpadlibscript that downloads the X.org log from the attachment, parses it and gets the driver name. He uses that script on 10 to 20 bugs each day. launchpadlibHe loves launchpadlib because it lets him automate things that are really boring to do by hand.
When there isn't an X.org log on a bug, he uses a Greasemonkey script that takes a stock reply asking for further details, inserts it as a comment and then sets the bug's status to "Incomplete".
Bryce finds it boring to expire bugs by hand, so he has a script that expires bugs after 30 days of being "incomplete". He is unsure if automatic bug expiry in Launchpad is happening.
He wishes he didn't have to expire bugs: he's rather know why people report bugs and then don't reply to requests for further information.
He has a graph of bugs filed against each driver package. He screen-scrapes from the bugs file in Launchpad and stores the data in JSON files. He looks at it every couple of days -- likes working with graphs -- as it's an easy way to see if there's a build-up of bugs around a particular driver.ds never replied so he expired it.
Launchpad does take a while to load so he loads up multiple bugs at once.
It would be really nice if users could set bugs to wishlist.
Sending bugs upstream
Bryce sees his job as improving the quality of the bug report to a point where upstream can actually fix it.
The trick is to do that as quickly as possible because the sooner upstream see it, the more likely the bug will be interesting to them. Their codes changes a lot, so it's important to get the bug up there really quickly.
In some cases, he imagines he could automate this entirely.
Most bugs that get fixed are a result of him sending the bugs upstream and upstream fixing it. He then takes upstream's patches and applies them.
First thing he does is an advanced search: he searches on confirmed and triaged bugs and those that are not known to affect upstream (excludes bugs he's already filed upstream previusly), sorts by newest first.
Once he's sure it's not a packaging bug, he forwards it upstream. He believes there's a way to forward upstream in LP but doesn't know how.
Usually the way an end-user writes their bug report is not suitable for upstream, so Bryce copies their original report into the Bugzilla report but provides his ownsummary at the top. He gives the name of the reporter, so upstream knows it's not his bug. He then gives a link to the originak Launchpad bug.
Then, one by one he downloads each attachement from the Launchpad bug report and attaches them to the Bugzilla report. Once he's finished in Bugzilla, he goes back to the Launchpad bug report and uses "Also affects..." to link it to the Bugzilla report.
The final step is to tell the reporter that he's pushed the bug upstream and that they should subscribe to it and follow-up any questions. He'd rather just be able to subscribe the person himself but they're not necessarily using Bugzilla at Freedesktop.org!
If the person doesn't subscribe, upstream asks questions and then it ends up in a black hole, which wastes his time.
He has blogged his ideas for how to minimise this back and forth and has created a tool that helps him
He describes the tool as being "pretty crude". He types in the bug number that he wants to upstream and it uses launchpadlib to load all the info into a form. It extracts all the info from the bug and its attachments, saving him a lot of time. It maps the Launchoad importance and priority to the corresponding ones in Bugzilla. All he has to do is review what he's going to send upstream, edit where necessary, then click "Send upstream". It automatically pulls up the bugzilla page with things pre-populated, using a POST.
He can then review it in Bugzilla, it's all filled in from his tool, usually he just has to click OK. Unless the person isn't already in freedesktop.org bugzilla! He may have to remove the person.
The bug report is then in Bugzilla and Launchpad. He still has to download and add the attachments manually because launchpadlib is very slow with attachments. It's quicker for him to do it manually. He has a bug filed against launchpadlib about this.
Bryce says it'd be really nice if LP handled all this for him as there's only so far he can with his own workarounds.
Bryce's other custom tools
Bryce generates a number of reports based on Launchpad data. One of those uses tag info.
Bryce uses tags to denote the symptom of a bug: e.g. crash, corruption, resolution, etc.
He has a launchpadlib script that tries to detect the symptom of a bug report by looking at the report's description and any attached logs. If there are no logs, the script posts a comment asking for them. If it can detect the symptom, it applies the tag right away. He runs this as a daily cron job on all bugs marked "New". It also tries to fix the title by appling the chip name and other relevant information.
His symptom report allows him to see what symptoms there and in what quantity. He combines that with another of his tags -- graphics chip id -- and that enables him to see what symptoms occur on which chips. For example, he may see a high number of corruption reports on a certain chip. That lets him see if the same bug is reported multiple times or perhaps if there's a common way to fix several different but related bugs.
He'd like to write a script that checks for the symptom and then walks the person through what they need to do next. For example, if it's a corruption issue he'd like his script to post a comment along the lines of, "Please take a photo of the screen and attach it".
He says that they're taking a symptom-led approach to apport, now, which asks the bug reporter about their symptoms.
He would like to see better guidance for users who file a bug report but don't understand the bug process. Perhaps there's a better way for them to get what they need without going to the bug tracker.
Some users are having problems with their system and need support so they come to the bug tracker. We maybe need to direct people to a better location for dealing with non-bug problems.
Other tools
Sourceforge is a really bad bug tracker. He has used probably all the other bug trackers out there.
Launchpad collaboration
Launchpad is a place where lots of people interested in bug triage can collaborate on bug triage. It's also a way for users who have bug to share knowledge about the issues they're having and to help each other fix those bugs.
Launchpad is not effective as a tool for collaborating with upstream. They don't look at Launchpad and they don't go to Launchpad to share information. They want control of their own bug trackers and Bryce feels they see Launchpad as a bug tracker just for Ubuntu.
Other parts of Launchpad
He feels he knows Launchpad very well and that he understands all the quirks but there's always something surprises him. He never looks at Answers or Translations.
He'd like to see a lot more improvements in launchpadlib functionality. He wants better ways to handle a collection of bugs in one go, so he can process them all the same way in one go.
For example: there are people who may have a bug but don't know how to describe it and they need some support in how to describe it and find out what's wrong. Around 80% of the bugs Bryce works with are like that!
Raw Notes
From: Matthew Revell Subject: Launchpad user testing: Bryce Harrington Date: Thu, 19 Nov 2009 22:28:47 +0000 Again very rough notes: Bryce Harrington Bryce maintains the X.org stack in Ubuntu. That's packing of x.org components, fixing bugs, doing bug triage and docs. Works from home. He maintains a number of source packages for X. Because most people don't know where to file a bug for an x issue, he says to file about x.org and he then moves to the right package. So, that's his incomign bug queue. Some belong on x.org but most don't, esp those that don'thave an importance set. One of his tasks is to figure out which package to move them to. Usually he's looking for which video driver the person is using. In the example Bryce is looking at, the reporter didn't include the right log files. Often people will file a bug in the wrong place and then the bug will get moved to something that Bryce looks after, so often he'll come into a conversation halfway through. Bryce has a Greasemonkey script: he can write a stock reply and save it and the script will insert the boilerplate, set the bug to incomplete. When someone has provided the right info -- log file -- it's easy to see what driver tehy're using and move it to the right package. So, Bryce has a script that d/ls the x.org log from the attachment, parses it and gets the driver name. He uses it for 10 or 20 bugs per day. launchpadlib script. He loves launchpadlib because it lets him automate things that are really boring to do by hand. If he has a 100 bugs to update, he can write a script that does them all exactlty the same every time. It's boring to expire bugs by hand, so Bryce has a script to expire bugs after 30 days. Is unsure if automatic bug expiry in Launchpad is happening. Wishes didn't have to expire bugs. Wants to try to identify why people are filing bugs are not following up. Once a bug has been moved to a more appropriate package -- he goes to the Intel video driver as an example -- Has a graph of bugs against driver packages. Screen scrapes the bugs from LP and stores the data in JSON files. Looks at it every couple of days. LIkes graphs. There's a big drop in the graph, which is where a whole load of bugs expired. He sent a bulk reply to a bunch of people, loads never replied so he expired it. Most bugs that get fixed are a result of him sending the bugs upstream, upstream fix it, he then takes their patches and applies them. First thing he does is an advanced search: searches on confirmed and triaged bugs and those that are not known to affect upstream (excludes bugs he's already filed upstream previusly), sorts by newest first. Looking at an individual bug, there are many files attached because he has an apport hook. Some people still file without using apport. Common case, they file against some other package using apport and it gets moved to X so he doesn't have the right files. If there are no files, he doesn't spend time looking at. Once he's sure it's not a packaging bug, he forwards it upstream. He believes there;'s a way to forward upstream in LP but doesn't know how. Really nice if users could set bugs to wishlist. He has everything bookmarked and navigates through the bookmarks. Has a book that pre-fills the bugzilla page with a little bit of info. Freedesktop.org Bugzilla. Usually the way an end-user write the bug report is not suitable for upstream, so Bryce copies their original report into the bugzilla report but summarises at the top. He gives the name of the reporter, so upstream knows it's not his bug. He then gives a link to the LP bug. One by one he d/ls the attachment files from LP, then uploads them to the Bugzlla report. Then, when that bug's created, he'll come back to LP and will mark the original report as "Also affects package" and then copies the URL of the bugzilla package. Then the final step is to tell the reporter that he's pushed the bug upstream and that they should subscribe to it and follow-up to any addresses. He can't do it. He'd rather just be able to subscribe the person himself but they're not necessarily using Bugzilla at Freedesktop.org! If the person doesn't subscribe, upstream asks questions and then it ends up in a black hole. Wastes his time. Has ideas for minimising the back and forth: blog post (drupal/upstream-cgi) explains it in great detail. It is pretty crude but he types in the bug number that he wants to upstream and it uses launchpadlib to load all the info into a form. It extracts all the info from the bug and its attachments, it saves him a lot of time. It maps the lp important and priority to the corresponding ones in Bugzilla. All he has to do is review what he's going to send upstream, edit where necessary then click "Send upstream". It automatically pulls up the bugzilla page with things pre-populated. He does with a POST. He can then review it in Bugzilla, it's all filled in from his tool, usually he just has to click OK. Unless the person isn't already in freedesktop.org bugzilla! He may have to remove the person. It's then in Bugzilla and LP. He still has d/l and add the attachments manually because launchpadlib is very slow with attachments. It's quicker for him to do it manually. He has a bug filed against launchpadlib about this. It'd be really nice if LP handled this for him. There's only so far he can with his own workarounds. He generates a number of reports based on LP data. One of those uses tag info. One of the things that he does is to tag based on the symptom of the bug -- crash, resolution, etc. He has a script to detect the symptom and then apply the right tag. He then looks through the symptom report to see what symptoms there are. Another thing he tags is the chip id. In his report he can sort by symptom, so he can see that e.g. there are two bug reports with a corruption tag that are on the same chip. Maybe the same bug or maybe that he can fix the same way. LP takes a while to load so he loads up multiple bugs at once. One of the things that he does that's a bit different is that he treats the NEW state as being completely unprocessed. He has a script that takes all NEW bugs and does some checks on them. launchpadlib, runs as a daily cron. What this script does is to look through the description, see if there are any logs attached (if not, it'll automatically ask for them). If the rights info's there, it'll parse it and try to determine what tag it should apply. It'll fix the title too so it gets a better descriptive title. It'll add the chipname to the title. One thing he wants to do is, if he knows the sympton, he wants to write a script that'll walk the person through what to do next -- e.g. corruption issue "Please take a photo of the screen". his job is to improve the quality of the bug report to a point where upstream can actually fix it. The trick is to do that as quickly as possible because the sooner upstream see it, then more likely it'll be interesting to them. Their codes changes a lot, so it's important to get the bug up there really quickly. In some cases, he imagines he could automate this entirely. One thing they've started doing is to take a symptom approach to apport. It leads them to file a good bug report by asking them about the symptoms. Hardly ever works on Inkscape any more. If he had the time, he would use a similar process. Sourceforge is a really bad bug tracker. He has used probably all the other bug trackers out there. Collaborative: it's a place that lots of people interested in bug triage can collab on bug triage. It's also a way fo rusers who have bug to share knowledge about the issues they're having to help each other fix those bugs. LP is not effective as a collab tool with upstream. They don't look at LP. Upstreams don't go to LP to share info. They want control of their bug tracker, they see LP as a bug tracker just for Ubuntu. He feels he knows LP very well and that he understands all the quirks but there's always something surprises him. But he never looks at Answers or Translations. He'd like to see a lot more improvements in launchpadlib functionality. He wants better ways to handle a collection of bugs in one go -- process them all the same way in one go. Would also like better guidance for users that file a bug report but they don't understand the bug process. A better way for them to get what they need without going to the bug tracker. Some users are having problems with their suystem, and need support so they come to th bug tracker. We maybe need to direct people to a better location for dealing with their problem. So, there are people who may have a bug but don't know how to describe it and they need some support in how to describe it and find out what's wrong. Around 80% of the bugs Bryce works with are like that!