CoreDevApplication

Differences between revisions 14 and 15
Revision 14 as of 2011-09-01 17:56:30
Size: 7517
Editor: brian-murray
Comment:
Revision 15 as of 2011-09-06 22:14:25
Size: 8537
Editor: static-50-53-79-63
Comment:
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:
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 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.
Line 68: Line 68:
== <SPONSORS NAME> ==
=== General feedback ===
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.

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

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". Smile :) 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.

<SPONSORS NAME>

General feedback

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.


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


BrianMurray/CoreDevApplication (last edited 2011-10-22 07:13:13 by vorlon)