I, Monty Taylor, apply for upload rights for package(s) drizzle, gearmand, libdrizzle, libinnodb, libmemcached, python-drizzle.

Who I am

I am Monty Taylor (mtaylor on IRC). I am a Free Software Hacker currently working for Rackspace as a developer on the Drizzle project. Before working on Drizzle, I was a Senior Consultant for MySQL, Inc. specializing in clustering and high availability. I prefer hacking in Python and C++, although I regularly also hack in both m4 and Java (and just did some vala hacking this last weekend) When I'm not hacking, I work as a theatrical director and lighting designer. I also travel extensively, both for work and for pleasure, and try to attend and/or speak at as many of the good conferences as I can. So far this year I've done linux.conf.au, UDS-M, the MySQL User's Conference and the first Texas Linux Fest.

My Ubuntu story

My involvement

I started using Debian in 2001 and moved to Ubuntu in 2005. I've been packaging software for Debian also since around 2001 and have been making use of Launchpad's PPAs since the day they were released. I'm a big fan of both bzr and launchpad and have been successfully involved in getting two different companies to use them for all of their open source development. The release cycle and the fact that the bug tracker isn't email based are both huge wins over Debian.

I think I'm what is best referred to as an opportunistic developer or an interested upstream... I don't have a broad enough interest in just working on random packages to fit the MOTU model very well. I am usually quite pedantically interested in making software I'm involved with as an upstream work properly, and if a package in the archive is giving me issues, I'm quite happy to fix it.

Examples of my work / Things I'm proud of

I currently maintain the Debian packages, through sponsors, of all of the packages listed above. I also maintain a PPA with all of them backported to karmic and intrepid. I'm currently spending most of my packaging time developing the drizzle package, as it's going to be rather more complicated (many plugins) than the others. All of my upstream software is developed on launchpad (with the exception of libinnodb, since that's being developed inside of Oracle somewhere)

I'm quite keen to follow current or future standards or best practices as soon as they exist. To that end I manage all of my packaging using bzr-builddeb and the pristine-tarball model. I make sure my packages are lintian clean with extra warnings turned on and I try to keep them updated with new thoughts, like quilt format, as soon as I can.

Areas of work

I'm obviously a database hacker... But I'm also a big build-tools guy. Outside of packaging, I've been working on a set of m4 macros (and now a set of quickly templates) to allow for easier, stricter and better C/C++ development using autotools called pandora-build. I'm also working on a set of hudson plugins to integrate with project state on Launchpad, so that merge requests can trigger automated build. (similar to tarmac, but integrated directly into hudson)

Things I could do better

Since I maintain the packages for Ubuntu by uploading them to Debian (easiest way for me to upload them right now), bugs I receive come through the Debian BTS. I could do a better job of responding about my status on them - but I can never remember the Debian BTS email commands. I imagine this will be easier once I can interact with those bugs via Launchpad.

Plans for the future

General

What I like least in Ubuntu

I actually don't have any major quibbles with Ubuntu. The need for a source package if I'm keeping my packaging in bzr is a little crufty, but I don't believe I'm the only one with that opinion- and I know it's in work, so I'll probably just wait on that. My main plans for improving Ubuntu are to make sure my packages provide the services they need to.

I *may* at some point try to help figure out the Java packaging situation, which is of course completely crap. I have some software that I'll be needing to package over the next year or so that will need a better story here, and as an opportunistic developer, I suppose that will be a good time to work on it.

I'd also love to convince the GTK folks to stop installing their headers into subdirs of /usr/include... but I imagine that's a losing battle.

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

CategoryPerPackageUploaderApplication