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).

The Tarmac team is more than pleased to announce the release of Tarmac 0.2. Tarmac has received many improvements and features in the last few months, and, thanks to the efforts of many who sprinted yesterday, Tarmac 0.2 has had some great polish applied to it as well.

Tarmac now supports the ability to run a command on merge previous to commit, and, should that command fail, reverts the change and alerts the user to the failure. Tarmac supports this through its new plugin system. Tarmac 0.2 is also packaged with a Commit Message Template plugin to enforce a standard commit message on merge, and a plugin for notifying the CIA.vc service of new merges.

Other notable features include a web interface for checking the status of Tarmac, improved conflict handling, updated documentation and preliminary Windows support. Also, Tarmac now properly attributes the author of the merge commit to the author of the last merged revision. For a list of all bugs fixed, see the Tarmac 0.2 bug list.

So I counted my fingers and toes (including thumbs) and I still can't count how many people have asked me about the possibility of having the functionality of Tarmac (automatic merging) built into Launchpad. The short answer is "No." The long answer is also "No."

There are many reasons for this. The first one I can come up with is the test suite. Sure, you can automate the merging of branches, but c'mon, what's the point of automating it if it's just going to propagate breakage? So the running of tests is relatively essential in automated merging. Elliot got a patch into Tarmac the day after 0.1 to do just this, and I have recently refactored it to work as a plugin. So, for instance, Entertainer can have approved merges, and Tarmac will check out a fresh copy trunk, merge in the branch, and run the tests. If the tests pass, it lands, if not, then the test output is added to the merge proposal. The problem with this is that many test suites take a very long time to run. Others may be quite CPU intensive. As one can imagine, that can require a lot of hardware.

Now, think of test suite you're running. Who wrote it? Not the Launchpad folk. PQM has put a lot of effort into making sure that the tests are run in a sandbox, and not in an environment that would have security implications. In fact, I've put a lot of thought into how to run the tests in a chroot environment for the Tarmac instances I maintain. This is quite a complicated setup.

Lastly, you may need a build environment. Maybe you're working in Windows, or you need a database, etc. These things are pretty specific to an environment. The possibilities are endless. This also has huge hardware implications.

Bottom line: Provide your own test environment, run Tarmac on a cron, make your development team happy.

Side note: I'd love to see if Tarmac would run on Windows. I don't have any Windows machines around, so (for bonus points) would someone please volunteer to try it there? Update: John Meinel was awesome enough to hack on Tarmac enough to get it running on Windows, and the branches have been submitted for review. This means that Tarmac 0.2 will have Windows compatibility as well. Woot!