I, Wookey, apply for core-dev rights.
Who I am
I'm a long-time Debian developer, having joined up in 2001 (https://nm.debian.org/nmstatus.php?email=wookey%40aleph1.co.uk), working professionally on Arm Linux since 2000ish, at Aleph One Ltd, Toby Churchill Ltd, and now Linaro (as an ARM secondee). I've been a free software developer since 1990 when I started writing Survex with Olly Betts (http://survex.com/). I've been involved with open hardware projects since 2002: LART, Balloonboard.org and iEndian (for whom I worked from 2007-2010).
My Ubuntu story
I only used Ubuntu for inexperienced users I was responsible for, such as my mother and my boss at Aleph One, until I joined Linaro, where much of the work was done using Ubuntu process and infrastructure and in the distro, so I got to find out how it worked, and how things were done. I was originally quite surprised how different the processes are from Debian despite the similarities in the software itself.
I have been working on cross-building, multiarch and armv8 fixes throughout the distro generally initially with xdeb and pdebuild-cross and now with multiarch and thus work with a wide range of packages. The primary focus has been on fixing the tooling to make cross-building straightforward, but there have also ben a lot of individual package cross-fixes.
I'm working on core stuff to do with cross-building, multiarch, dependency analysis, bootstrapping and armv8. So my work tends to cover all packages (or at least the core couple of thousand packages people sensibly want to use in smaller systems). The ability to upload cross-bulding and multiarch fixes across the board in Ubuntu as well as Debian will help get this stuff actually implemented in finite time.
Examples of my work / Things I'm proud of
Doing the arm64 toolchain bootstrap, based on Quantal, including making linux-source, eglibc-source, gcc-source and binutils-source packages updated with arm64/aarch64 upstream patches and making an arm64-cross-toolchain-base package based on the amrel/armhf version, then doing the full 3-stage bootstrap, with plenty of pain along the way.
The eglibc2.16 work, getting it working on arm64 and amd64, with gcc4.7 was quite tricky. Great support from infinity and doko in gettin all this uploaded quickly. I have then been able to use this along with sbuild, cross-build-essential, reprepro, dose-debbuildcheck and dpkg with build-profile support to start the arm64 bootstrap. http://wiki.debian.org/Arm64Port
I added cross support to sbuild (building on a previously started effort by Hector Oron) so that standard components can be used to do cross-builds. That work was done directly with sbuild upstream. Added staged build support to dpkg-buildpackage.
Backported multiarch support from python 3.3 to 2.7.
Not cross-related but I was pleased with it: Tracking down the java-helper build failure breaking every java-helper using package upload in Debian/Ubuntu.
It's been good to have some pressure to improve the cross-building and bootstrapping state from Ubuntu.
I've also done quite a few GSOC projects around this area, which has been realy interesting. Students' abilities are highly variable, but some really good work has come out of that this year.
Not sure if non Ubuntu stuff is of interest: The Psion netbook project was a particularly fine effort back in 2004/5, showing what can be done with a really good team and good technology (we did a linux image for the original strongarm 'netbook' based on OE, which was way ahead of its time).
YAFFS (nand flash filesystem) is one of the other major things I've been involved with of note. A couple of the articles I wrote on arm kernel porting back in 2002ish are still top google hits(!) http://www.glomationinc.com/PortingLinuxKernel.pdf
I take an interest in the legal and licencing side of things: I put a lot of time and effort into the software patent debate and CII directive in the EU in 2005 as part of FFII-UK, and on behalf of Aleph One and Toby Churchill. Preventing that from becoming a much worse situation was a huge achievement. I am now a member of the Freedom Task Force group of Free Software lawyers/legal experts, primarily due to an interest in Open Hardware, but also representing Debian.
I have been responsible for the Embedded Debian project since 2004, even though others have done the bulk of the actual work.
Areas of work
I've filed a lot of cross-build and multiarch and arm64 patches over the last couple of years, and have had great support from ColinW, Vorlon and infinity with uploading stuff.
I wrote much of the multiarch-cross spec and the multiarch howto.
I also originally worked on xdeb a fair amount, put pdebuild-cross and multistrap into the archive, improved pkg-config for cross-work, and helped Vorlon with multiarch fallout. Over the precise period I've filed quite a lot of patches for cross-building and multiarch cross-dependency support.
I've done quit a lot of work on analysis, documentation and specifications for fixing of the cyclic-dependency and cross-building issues, and have set up a simple cross-autobuilder so that uptodate results of the current cross-buildability of the archive is available online: http://people.linaro.org/~wookey/buildd This is a long-term effort. Having that info available to all means that we can report on it, packagers can check their status, bugs can be reported semi-automatically and so on. http://people.linaro.org/~wookey/buildd/quantal/sbuild-ma/status.html
I have done a lot of packaging and build-system work over the years, including for proprietary stuff run on top of Debian (at TCL)
I also maintain some Debian packages, which are essentially cave-surveying and emdebian/cross-building packages. http://firstname.lastname@example.org I work closely with the various upstreams, all of whom I know well, and retain good relations with. Ubuntu patches are passed into the Debian packages, and upstream if appropraite.
Some patches and bugs:
eglibc2.16 arm64 support: https://bugs.launchpad.net/debian/+source/eglibc/+bug/1068369
kernel arm64 support: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063895
dpkg stage/profile support: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661538
dpkg-cross fix: https://bugs.launchpad.net/debian/+source/dpkg-cross/+bug/659805
python 2.7 multiarch backport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683755
Trivial cross/mulitarch-bug: https://bugs.launchpad.net/debian/+source/noweb/+bug/967380
Cross-build fixing bug: https://bugs.launchpad.net/debian/+source/consolekit/+bug/984962
Cross-build fixing bug: https://bugs.launchpad.net/ubuntu/precise/+source/libsepol/+bug/1056975
pkg-config-tripet support: https://bugs.launchpad.net/debian/+source/pkg-config/+bug/771567
Things I could do better
On first starting to use Ubuntu infrastructure such as bzr and launchpad, I made a bit of a pigs ear of updating xdeb in Debian and Ubuntu in parallel, due to not using bzr branches and merging the way the rest of the team expected and putting a version into Debian with the same version number as in Ubuntu but slightly different functionality. This was due to not properly appreciating the relationship between the distros when 'upstream' is effectively Ubuntu bzr. That got sorted eventually, and a lesson was learned.
Plans for the future
Now that armv8 toolchain bootstrap is done in a forked-quantal repo we will re-do it for Ringtail (should be a simple matter of uploading the linux arm64 support fixes, and building arm64-cross-toolchain-base) and for Debian (where I plan to try a pure-multiarch bootstrap using ThibG's GSOC work).
Build/fix lots of cross-build failures in packages
Get dpkg stages/profiles mechanism agreed
What I like least in Ubuntu
Having to develop software (xdeb) via bzr and team code-review has been a bit of a culture shock. I've always previously worked where I was ultimate arbiter on uploads and what was done in the Debian (and thus Ubuntu) versions of software. Still, I think I've got the hang of it now, and it does catch errors and improve code quality, in exchange for being rather cumbersome. This isn't a dislike as such - just something different to get used to.
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.
Wookey's summary above of what we've done has been pretty accurate; I've worked with him on various changes to xdeb (graphing, loop detection and resolution, build-dependency satisfaction, etc.) and on trying to organise cross-build improvements to Ubuntu. This is definitely the sort of thing that requires core-dev privileges to do usefully; a broad-but-shallow set of changes need to be made, and the interesting ones are pretty much all in the core system. I'm happy that he knows what he's doing (due to a long history in Debian and substantial concentration on cross-build work recently) and has good taste in terms of how things should be fixed.
Specific Experiences of working together
As Wookey says, his revision control practices left something to be desired at first, but I think that's sorted out now. Generally my main whinge is that he's taken a while to get cross-build patches merged into Ubuntu, which is exactly the kind of thing that a grant of upload rights tends to correct!
Wookey's graphing work in xdeb (presented at DebConf this year) has been excellent; it's exactly the sort of organisational/visualisation thing that I never bother to do but that's very useful when trying to attack a large problem, and especially when trying to distribute it across multiple people. I think a good next step will be automating this and making it something that we can see progress on in mainline Ubuntu, in continuous-integration style.
Wookey has a great fundamental understanding of Debian and Ubuntu, and how the various bits all fit together, as well as general toolchain and cross-building expertise. His skills would be quite valuable to us, and his ability to upload his many build fixes directly would be helpful.
Specific Experiences of working together
I've sponsored a lot of packages for Wookey over the last year or two, and he's learned a fair bit, through review and feedback, about Ubuntu-specific bits that make us slightly different from the Debian packaging he was already very familiar with. I'd heartily recommend getting him upload rights, so we can stop sponsoring his patches.
== <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 ===