I, William Grant, apply for core-dev.

Who I am

I'm a long-time Ubuntu and Launchpad developer, and nowadays a member of the Ubuntu Engineering Continuous Integration team at Canonical.

My Ubuntu story

I've been involved with the larger Ubuntu community since 2005, and in 2006 I became a member and a MOTU. In 2009 I focused more of my efforts on improving Ubuntu's pain points in Launchpad, and in 2010 was hired by Canonical to work on Launchpad full-time. Recently I've become more directly involved in Ubuntu again, primarily with the arm64 and ppc64el porting efforts.

My involvement

Porting, bugfixing, QA tooling, all sorts.

Areas of work

I've worked in many different areas over the years, though most recently in bootstrapping Ubuntu's arm64 and ppc64el ports. This has involved much ugly code porting, many thorny test suite issues, numerous trivial autotools-related uploads, unbitrotting a lot of upstream code and packaging, tracking down obscure crashers in kernel and toolchain ports, and everything else that falls out from building the entire archive from scratch. Most of the arm64 work was very late in the Saucy cycle, so involved cherrypicking minimal patches from upstream and close coordination with the release team to keep everything compatible with freezes.

Most of my recent uploads have been sponsored by cjwatson, doko, infinity and slangasek, and can be found at https://launchpad.net/~wgrant/+uploaded-packages.

Much of my past focus has been on trying to beat universe into some kind of quality and security. I also maintain qa.ubuntuwire.org and many of the tools on it.

Things I could do better

I've lately been somewhat inconsistent in forwarding patches to Debian and further upstream. After spending my early years gardening universe I very much know the importance of minimising delta, so I'm improving back to my previous standard.

Plans for the future

General

In the immediate future I'll be fixing a lot of bits and pieces for ppc64el and arm64. But after that I hope to return more to general work around the archive, particularly aided by not having to pester people for trivial fixes to packages in main and restricted.

What I like least in Ubuntu

The wildly differing implementations of version control and continuous integration around the archive make it awkward to efficiently work across a varied set of packages. Most packages are maintained in UDD Bazaar branches, some in alioth git, a few in separate packaging branches, while others have no VCS at all. Certain important software needs to go through Jenkins-based CI systems, and uploading changes as if they were normal packages can block their normal development processes. These different ways to do the same thing seriously slow down development, and it's not always easy to see which apply to a given package. Like my previous point, this often adds an extra delay of having to poke people before making a trivial, clearly safe change.

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.

SteveLangasek

General feedback

While I've only sponsored a few packages for William into Ubuntu recently as part of a new port bringup, I've known him in the Ubuntu community for years. When sponsoring these packages I finally got tired of listening to him demure about how he's not active enough to apply for core-dev, and declared that I considered him to have well exceeded the threshold for applying due to managing to simultaneously annoy four different existing core-devs with needing to sponsor his uploads that required no correction or review.

I have complete trust in William's ability to upload packages without the need for someone looking over his shoulder, and to ask for help when there's something he doesn't understand. There is no question in my mind that he should be granted core-dev status.

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

CategoryCoreDevApplication