I, Monty Taylor, apply for upload rights for package(s) drizzle, gearmand, haildb, libdrizzle, libinnodb, libmemcached, python-drizzle and pandora-build.
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
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 couple of PPAs:
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
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.
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.
I've reviewed a few things from Monty in Debian - where most of his packages go first. I'm also the maintainer for pandora-build in Debian. Monty is smart, learns from experience and generally knows when he needs help or is good-to-go. I'm confident that if given upload rights to the packages he's requested that he'll help improve them in Ubuntu, work with Debian to maintain an appropriate delta, and generally fix things in the right place: upstream | Debian | Ubuntu depending on the issue that has turned up. Oh, and he should add pandora-build to the list, or I'll have to find a fish to slap him with at UDS-N.
== <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 ===