I, Andy Whitcroft, apply for core-dev.
Who I am
Tell us a bit about yourself.
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 + 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 am now 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. I have also been the Kernel Release Manager for a number of releases. After my first year in the Kernel Team I applied for and was granted Kernel Per Package Upload rights. 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, though for non-generalist this has been less successful than hoped. 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.
More recently I have been working 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.
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 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.
More recently I have been a member of the Plus One team working (in particular) on FTBFS and NBS packages, working with a small team under the mentorship of AdamConrad. This worked well as most of us were new to the processes and requirements of this work and were able to learn together, documenting as we went. 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. The the majority of that work was sponsored by AdamConrad who was keen to explain the needed steps and quick to catch errors.
A fuller list of packages I have been involved with is in launchpad: https://launchpad.net/~apw/+uploaded-packages
Things I could do better
Previous patch pilot rotations have been a source of frustration due to lack of skills. The recent Plus One rotation has allowed development of those skills and I hope to be more productive on this rotation in the future. 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 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 Debian and Ubuntu kernel teams, we have recently embarked on shared ownership for an upstream stable tree and that should provide opportunities to expand collaboration.
What I like least in Ubuntu
Please describe what you like least in Ubuntu and what thoughts do you have about fixing it.
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@.
As a sponsor, just copy the template below, fill it out and add it to this section.
== <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 ===