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

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

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.

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