Yes. Yes they are.

I'm crap at packaging. My mind has never really grokked all the packaging things. Also, I make packages, and then they quickly get out of date as I continue to work on the upstream part, and so then there's this big hill to get over when I actually need to package it again.

Enter source package recipes. It's what Aaron Bentley and I have been working on for the past 6 months. Basically, take two bzr branches, put them together using a recipe, and make a source package (and eventually a binary package) out of them.

My first recipe got built into a binary package two days ago, but I just noticed it.

Now I want to package everything.

I was entirely happy to happy to announce a new version of Tarmac, 0.3. In fact, I was so happy that I went again and immediately did another release of Tarmac, Tarmac 0.3.1. Tarmac 0.3.x series brings a whole slew of fixes, including fixing more than half of the bugs filed against Tarmac. In fact, there are no more bugs with a higher importance than Low currently (ideally, people use the software and find more for me to work on).

Tarmac is a tool for automatically landing branches that have been approved for merge through the Launchpad code review system. It uses the Launchpad API to find these branches, and has a variety of features to automate their merge and management.

Tarmac 0.3 is also a complete re-write of most of the system. Notably, this means that Tarmac can be used on branches that aren't the development focus. I'm sure this will make Ted Gould happy, but the real reason I did this was help in the managing of all those official source package branches on Launchpad.

The Plugin architecture has also been reworked a bit as well. Since I spent so much time writing documentation for Tarmac, I realized how icky it was to write plugins. If you have plugins from 0.2, you'll need to port them to 0.3. You'll also need to port your configuration to Tarmac 0.3.x, since the configuration has changed a bit.

The final big thing to notice is that Tarmac is getting entirely more entwined with bzrlib (because it's such an awesome library even outside of bzr) by stealing it's command code. Tarmac is only one script now, and the first argument is the actual command.

You can find Tarmac 0.3.1 here. I'm working on packaging it now (although I'm really slow packaging, mentoring desired).

A few times during UDS, we've talked about setting up a Launchpad development environment. I think it'd be great if the community really got involved in making Launchpad better, and I don't think I'm alone on the Launchpad team thinking that. However, setting up the development environment is kinda scary. Among other things, the script that sets up a Launchpad development environment (rocketfuel-setup), deletes all postgres databases to set up its own, edits yours /etc/hosts and your apache configs, and adds some PPAs that may interfere with your system packages (although it's been a while since it did that to me.)

To combat this, and allow me to fart around on my system on the weekends without breaking my environment, I do all my development in chroot environment. This means Launchpad can eat my system, and my system can't eat my Launchpad. I've been working this way for almost 8 months now, and have found it to be much better than sharing spaces.

The one thing that I have had a problem with is the relationship between my desktop and the chroot. I figured that maybe I'd reach out to the community and see if they can recommend a path for putting some Compound W for some development warts I have.

When I start up my computer to work on Launchpad, I open two terminals and a gvim. Both terminals become chroot terminals by my typing schroot which then promptly get navigated to have my current branch's tree as the working directory. This means that these terminals are now utterly useless for anything but work in the chroot, which can be good for focus, but if I need to do anything else, I have to open another terminal to do it. Having lots of terminal windows open is generally a bad thing for focus as well.

Also, I run lots of Windmill tests. Windmill needs a browser, which needs an X display. I've been using Xnest -ac :1 &!; metacity &! outside of the chroot, and then setting export DISPLAY=:1 in my chroot in order to get X forwarded over. This is really sub-optimal, since it's a lot of crap to set up to run Windmill (which in and of itself is a lot of other crap to set up).

I would love nothing more than to modify rocketfuel-setup to be created in a chroot if I could find an easy way to work outside the chroot and just forward certain commands over to the chroot. I'm sure some server sysadmin has a great method for doing this. If you have a solution, a bribe can be arranged. If you're at UDS right now, even better.