I, Andy Whitcroft, apply for core-dev.
Who I am
I am Andy Whitcroft a member of the Ubuntu Kernel Team, employed by Canonical. I help to maintain the Ubuntu kernels and related packages for all actively supported Ubuntu releases. I am focussed on development projects for upcoming releases.
My Ubuntu story
I first met Linux with a RedHat 5.0 installation we used to create a firewall for our lab. We then moved to Debian as it was so much easier to manage with network updates. I worked on the Linux Kernel for about 5 years using a Debian based desktop install, finally moving to Ubuntu Hardy as it offered me Debian goodness, but without having to run unstable plus a handy kit of hand built packages. I no longer needed to maintain my own machine just to get work done. I then had the opportunity to shift my Linux Kernel focus to Ubuntu full-time joining the Ubuntu kernel team working for Canonical. I have worked on the Ubuntu kernel team for over 3.5 years now, primarily focussed on the development releases. I have assisted the release team at the last seven releases providing a local kernel presence. Most recently I have been on a rotation on the Plus One maintenance team.
I formally joined the Ubuntu kernel team the week after Intrepid shipped, first working as a member of the Kernel Stable Team, working on the stable releases and helping resolve bugs. Later I moved to the Kernel Development team focused on developing features in the development releases. As part of that I have been heavily involved in the kernel sessions at the Ubuntu Developer Summits. After my first year in the Kernel Team I applied for and was granted Kernel Per Package Upload rights. This allowed me to take ownership of the development kernel becoming the Kernel Release Manager for a number of releases. Over this period I have also worked on process surrounding the kernel, helping to shape the current release and update mechanisms. As a senior member of the team I have also had the chance to mentor a number of the newer members of the team, helping to bring them up to speed on our packages and process.
Outside the kernel I have been lightly involved in a number of kernel related packages. With my Kernel PPU rights I also joined the patch pilot rotation. More recently during the Quantal cycle, I have had the opportunity to have a rotation on the Ubuntu Plus One team, helping to clean up archive issues as they happen. Here I have been heavily involved in a number of library transitions and build failures across numerous packages. One of the best thing about working on Ubuntu is that it is possible, indeed encouraged to scratch that itch, to fix problems whereever you find them, and being on the Plus One team has allowed me to gain the skills to continue that going forward.
Examples of my work / Things I'm proud of
I have been heavily involved in the maintenance of the Ubuntu Kernel for over 3.5 years. I have been involved in both bug fixing and feature development and testing for the Development releases for much of that time. I have also been one of the main drivers in the ongoing maintenance, simplification, and update of our kernel packaging during that time. For example I was heavily involved in development and implementation of our union mounts solution reaching out into the installer packages to handle the transition. I have also been involved in dealing with a recent shift from 2.6.x to 3.x numbering for the upstream kernel which involved touching a number of packages which simply did not understand the new version format.
My recent stint on the Plus One team which has allowed me to work with a large and varied portfolio of packages from all over Ubuntu. During this time I was mentored by AdamConrad (infinity) who has sponsored a significant portion of my uploads. Of particular note I was heavily involved in a poppler18 to poppler25 library transition which involved both rebuilds and porting work. I also did some major porting work on the subversion testsuite which was impacted by security improvements in the underlying APR libraries. I also handled a db4.8 to db5.1 transition. The biggest surprise for me was the vast variability in packages, both in terms of languages used and of packaging, and patch styles. As we were working early in the cycle it was hard to make visible downward progress but significant numbers of packages we fixed and uploaded.
Areas of work
As a member of the Ubuntu Kernel Team a large portion of my uploads are related to the kernel packages (which I upload on my own recognisance), and packages surrounding the kernel (such as udev and initramfs-tools) which I have generally funneled through ColinWatson, SteveLangasek, and MartinPitt. Overall I have found them easy to work with and tolerant of my ignorance pointing me to relevant resources.
My formal rotation on the Plus One team has found me working (in particular) on FTBFS and NBS packages, on whatever is broken right now. I have found this particularly satisfying as a small amount of work can clear out niggling issues and help maintain quality in the development release. Since my rotation this work has continued on an informal basis and it is this work that I would like to continue going forward as a core-dev.
A fuller list of packages I have been involved with is in launchpad: https://launchpad.net/~apw/+uploaded-packages
Things I could do better
I have been very kernel focussed (in large part due to my role), I need to expand my knowledge and experience of other packages. The recent Plus One rotation has allowed development of those skills and I hope to be more productive on this rotation in the future; with core-dev bringing the oppotunity to widen participation. As with a lot of Ubuntu we tend to race ahead of Debian and it is easy to forget the great foundation they bring, I also want to work more with Debian feeding back fixes coming out of PlusOne and elsewhere.
Plans for the future
I would like to use my new skills to further participate in the Plus One rotations. I also would like to start mentoring other members of my team in these skills to allow them to take Plus One rotations and head for core-dev as well. I would like to strengthen the relationship between the Ubuntu kernel and the ports kernel teams, such as the lowlatency kernel for which I am starting a mentorship program. We have also recently embarked on shared ownership for an upstream stable tree and that should provide opportunities to expand collaboration with Debian.
What I like least in Ubuntu
The most complex part of trying to work on new packages is trying to find the original source. Are the UDD branches master, is some other bzr branch master, is the maintainer using something completely different, or indeed nothing at all. This is all made much more complex by the autoimporter and the maintainer trying to share the UDD branches in a lot of cases and much hilarity ensuing. It would be lovely if the VCS pointers were accurate, but rarely they are. At the very minimum I would like to see the possible options documented and broad advise how to check each formulated.
If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.
(NOTE: This is a copy-and-paste of my endorsement of Ricardo, as I'd been bugging them both to apply at the same time, and all the following applies to both. If it looks familiar, that's why. Andy's prettier, though. He made me say that.)
Andy is on my short list of people I really enjoy sponsoring uploads/patches for. He has both sets of skills that I think are quite valuable to a core-dev:
- A broad knowledge of Ubuntu/Debian, and how all the pieces fit together, and how not to break A by fixing B.
- An understanding of what he doesn't understand, leading to asking questions, or just plain not touching things he doesn't think he's qualified to break.
I have no hesitation whatsoever with endorsing Andy's application and have, in fact, been bugging him to do this for months. I've often joked that I don't want him to apply because then the quality of submissions I get to sponsor will go down (due to no longer having his in my queue), which I suspect is a pretty good reason to give him upload privs.
I've been working with Andy for years on a variety of areas where the foundations and kernel teams intersect; most notably we did lots of work a while back on the arrangements between GRUB, the kernel, and Plymouth necessary for flicker-free boot, and more recently we sorted out the infrastructure necessary for signed kernel packages together. He's been consistently a delight to work with and knows considerably more about what he's doing than he sometimes likes to let on. While he's clearly more comfortable in kernelspace, he's been getting rapidly more proficient in userland as well. At this point I trust him implicitly to get things right and am occasionally bewildered that he isn't a core-dev yet.
Areas of Improvement
Andy is still sometimes fairly confused about how bzr is used in Ubuntu, and in general could probably use more exposure to packages maintained in ways that differ radically from how the kernel is maintained. OTOH that's one of the things he raises himself in "What I like least in Ubuntu" and I think this is partly a matter of confusing thing being confusing. (I'm not worried about him getting things wrong due to this; he's entirely comfortable with asking questions.)
As a sponsor, just copy the template below, fill it out and add it to this section.
I've worked with Andy in a few areas over the years and found his standards to always be high. He always seem keen to adapt to better workflows and practices, and takes quality seriously. Whilst I haven't actively sponsored his work, I have reviewed and touched packages that he touched last, and they were of sound quality.
I am entirely confident that Andy wouldn't exceed his experience levels, and would take responsibility to resolve issues that he, or others introduced. He always seems keen to get involved in any area of Ubuntu development and it is therefore my opinion that him being a Core Developer would be a welcomed addition.
== <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 ===