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.

My involvement

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 pacakge 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.

General

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.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.

Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.

Kees Cook

General feedback

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.

TEMPLATE

== <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 ===