I, Brian Murray, apply for core-dev.
Who I am
I work for Canonical on the Ubuntu Engineering Foundations team as the Defect Analyst after having been a QA Engineer on the Ubuntu QA Team. I like hiking, rock tumbling, post offices and laffy taffy jokes.
My Ubuntu story
I have been using Ubuntu since 2005 and involved in the Ubuntu community since December 2006. My involvement initially started with triaging bug reports. However, as I reviewed more and more bug reports I wanted more automated ways of dealing with them. As such I have been involved in the python-launchpadbugs project (an API for Launchpad based on scraping web pages), the Launchpad greasemonkey scripts project, python-launchpadlib-toolkit and arsenal. I have actually done some Launchpad development. As I have been looking at bug reports I have also found a lot of bugs with patches and have worked to get those patches forwarded upstream and included into Ubuntu.
Examples of my work / Things I'm proud of
I have recently been focusing on the reducing the influx of automatic bug reports that we receive by preventing the reporting of bugs due to hardware failures. Additionally, I have created a duplicate signature for apport package installation failures that will allow the apport retracer to automatically mark these as duplicates. I have also been working on making bug reports more informative when they come up by writing and improving apport package hooks for a wide variety of packages. I believe that reducing the quantity of unnecessary bugs being reported and improving the quality of the bugs we get are vital to ensuring that we can make progress identifying important bugs and improving Ubuntu.
As I encounter bug reports I also think about the appropriateness of them for an SRU and in the event I feel the bug should be fixed in a stable release will take the time to build and test a package and get it sponsored. For example 797894, 814727, 797847, 346386.
Areas of work
I have worked on apt which produces apport package installation and preventing the reporting of these bugs in situations where the installation failure was due to a hardware issue.
I have worked quite a bit on apport and improving the information collected in bugs reported by it. Additionally, I added functionality to prevent the reporting of bug reports due to hardware errors. This work was done with Martin Pitt and Michael Vogt as a part of the better apport package bug reports specification.
I have been taking care of the kerneloops package and worked with the Ubuntu Kernel team to ensure that kerneloops was reporting the types of Oops reports that they really wanted and not cluttering their bug lists with bug reports regarding kernel warnings. Additionally, we worked together on tagging Oops reports with information regarding the driver in which the crash occurred.
I have written or modified apport package hooks for ubiquity, update-manager, linux, plymouth, software-center, system-config-printer, usb-creator, xscreensaver, vlc, cups, debian-installer, compiz and yelp.
Things I could do better
I could participate more in Ubuntu development by working on merging packages with Debian and updating packages to upstream software versions.
Plans for the future
In the future I plan to continue reducing the volume of unnecessary bug reports about Ubuntu, improving the information gathered in bug reports by creating and modifying apport package hooks. I would also like to participate more in Ubuntu development by working on updating some software packages that I care about particularly such as gpsprune, gpsbabel, gpscorrelate, mkgmap. Finally, I want to help more contributors get their work into Ubuntu packages and improve the quality of Ubuntu.
What I like least in Ubuntu
The thing that I like least at the moment is how hard it can be to find the right branch to use for some packages depending on which team happens to be responsible for that package. I think this can be made less confusing by ensuring that the Vcs-Bzr headers are up to date in packages. Additionally, in the event that a contributor happens to use the wrong bzr branch the team or person reviewing the merge proposal should do the work of getting it merged rather than asking the contributor to incorporate their patch into a new branch and setup a new merge proposal.
If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.
As a sponsor, just copy the template below, fill it out and add it to this section.
I've sponsored 16 unique packages from Brian (with a total of 25 uploads). The quality is very high. He has been doing packaging work steadily for a long time now, and I rarely ever have any suggestions to make when doing uploads. This tends to be a strong indication to me that it's time for someone to get full upload rights, since my role as a sponsor has shifted from "helpful" to "bottleneck". I trust Brian, and I think his attention to detail is excellent. More importantly, he knows when to ask questions and is a quick learner.
Specific Experiences of working together
Recently I worked with Brian on a kerneloops upload that was rather tricky. He had added some additional logic to avoid reporting meaningless warnings and fix up a few other things. Due to the Gnome 3 transition, several build dependencies had suddenly gone missing, and we had to figure out what was needed to get kerneloops building again. Brian was cool in the face of these irritating build failures that needed to be fixed even though they were unrelated to his changes. He secured help, understood what needed fixing, and carried through.
Areas of Improvement
While Brian has done a large number of merges already, I'd like to see maybe a little more work in this area. He is very experienced when it comes to apport behaviors and scripts, apt failure modes, and other bug-generating vectors, so I'd like to see more work outside that comfort zone.
I've worked directly with Brian on arsenal, python-launchpadlib-toolkit, the Launchpad greasemonkey scripts, and Launchpad itself, and followed his work on apport and other tools. Brian is always well studied in the problem he aims to solve, and quite attentive to detail. I think he'd make an excellent addition to the Core Dev team.
The common thread I see in the projects Brian undertakes is to improve the lives of package maintainers. He looks for ways to filter out useless mail or bug reports that would otherwise be distracting a developer. He finds ways to do rote bug work using automated scripts and bots, so developers are more able to focus on higher-value issues. His work on Launchpad, the greasemonky scripts, and similar tools serve to make common maintainer tasks easier to do. His apport work is fundamental in helping ensure that when a bug report is filed by an inexperienced user, it is much more likely to be actionable by a developer.
Brian has recently been a big help to the Ubuntu Kernel Team by focusing some of his efforts onto our large volume of kernel bug reports. A large majority of our incoming kernel Oops bug reports were just warnings (ie not an actual Oops). However, they were still being reported automatically to Launchpad and thus inflating our volume of bugs. Brian was able to provide a fix such that warnings are no longer automatically reported. This has helped reduce the kernel bug volume noise so that we can better focus our resources onto more important issues. Brian also helped us to categorize and tag our existing kernel Oops bug reports to the relevant driver which likely triggered the Oops. This has helped us distinguish the more problematic drivers within the kernel and drivers which likely need more developer attention. I'm confident that Brian's extensive background knowledge and experience with apport, kerneloops, and launchpadlib helped him tackle these issues for us and in a short period of time. What I'd really like to point out is Brian's insight into these issues and it was he that took the initiative to bring these issues to our attention and provide us a solution. It's clear that Brian's attention to detail and keen eye for spotting areas of improvement has greatly improved the quality and quantity of bug reports we see against the kernel and has helped improve our overall bug management.
I work with Brian since a long time, he is a great help with keeping the flood of bugs somewhat under control. With the amount of reports we receive currently automation is really much needed. Brian helps with that by adding apport hooks to packages, for me he added one to software-center and also greatly improved the apport integration that update-manager. I think Brian is absolutely ready for core-dev, all contributions I have seen are high quality and if he is unsure about a fix he will ask for feedback/review (which is a excellent quality for a core-dev
Specific Experiences of working together
One of the most recent examples of us working together was the software-center package hook, it could not been better for me, he asked me what information makes my life easier and contributed the right patch for a apport hook that automatically adds the right logs.
I've worked with Brian for years, having merged many branches of his and sponsored uploads for him along the way. He is a very competent developer and I have no doubt that he is ready for core development membership.
I sponsored a lot of apport package hook improvements for Brian. There were some minor errors sometimes, but in general the updates were fine. I didn't sponsor other kinds of changes for Brian so far, so I can't say more. Thanks Brian!
I've known Brian for four years, since I first started working at Canonical. He has been a continuous presence in the Ubuntu development community since then, and although the number of packages I've sponsored for him is fairly small (several uploads of apport and one of isc-dhcp), I have no doubt about his qualifications to be a core dev. When he doesn't know the answer, he does know how to ask smart questions; and he rarely needs to do that. I'm happy to see his interest in being more directly involved in the packaging side of development, and think he will make a great core-dev.
== <SPONSORS NAME> == === General feedback === ## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?) === Specific Experiences of working together === ''Please add good examples of your work together, but also cases that could have handled better.'' === Areas of Improvement ===