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.

Launchpad is open source today. All of Launchpad is open source as well, where it was before announced that some parts would remain proprietary. It's all there.

This makes me happy. That is all.

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!

Want to hack on Tarmac? Want to learn how to use the Launchpad API (or want to use your existing knowledge)? Want to learn to use bzr's functionality programmatically? There is a Tarmac mini-sprint scheduled for Friday, 10 Jul 2009 in #tarmac on Freenode. Tarmac 0.2 will also be released this weekend based on the work completed on Tarmac on Friday.

Also, if you'd like to know more about Tarmac, or would like to participate, please join the Tarmac Launchpad group and subscribe to the mailing list.

In a nod to Michael Bernstein's F/OSS License App for Web App Wednesday, I threw together some code that does a similar thing for Launchpad. Things rolled downhill from there to do some other really fun things, but I thought I'd stop and blog about the first result before hacking on the rest of the data.

The above image is the result of this hacking. I used the Google Charts API to create the pie chart. It's obvious that GPLv2 is the most popular license, being that 35% of all Launchpad projects are licensed that way.

I'm pleased to announce the first version of bzr-autoreview, a Bazaar plugin for automating Launchpad merge proposal reviews.

The concept is simple. Go to your local mirror of a branch on Launchpad, and simply type bzr autoreview. The plugin will do the rest. It finds every merge proposal against your public branch that doesn't yet have a review, gives you an editor pre-populated with the diff, and then, after your review, allows you to also vote.

I have many planned features, but I've been trying this year to release code instead of just writing it. The code's a mess because I was spanning hemispheres while writing it. I plan on cleaning it up in the next few days and releasing again.

Please see the README. You can download the tarball or get the branch. If you're really ambitious, I'd appreciate any patches, so please see the HACKING file. A special thanks goes to Elliot for giving me the idea in the first place.

I'd like to announce the release of Tarmac, the robotic landing bot for Launchpad. The idea is simple. You have a development focus branch that constantly needs to have branches landed on it, but you're too busy writing your own code to manually land them in trunk. Tarmac takes the difficulty out of this by checking your development focus branch for approved merge proposals, and merging them automatically.

You can read the README file, grab the Tarmac 0.1 tarball or just get the bzr branch with bzr branch lp:tarmac. This first release is just a little more than "the simplest thing that could possibly work" because I wasn't exactly sure what features were the most important to other potential users. This means feature requests and patches are most certainly welcome (it's why I use Launchpad). Please feel free to file bugs with the features you'd like to see.

Tarmac is licensed under the GPLv3.

So I had this idea for yet another Bazaar post about some more advanced topics, and concepts that my workflow has eventually evolved to incorporate. Among these concepts are shared repositories, lightweight checkouts, and branches with no working trees. I'll do my best to explain these concepts, and why I find them to be of benefit, but if there are questions, please feel free to leave a comment and I'll do my best to answer those questions.

$ mkdir ~/Projects/repos/loggerhead
$ cd ~/Projects/repos/loggerhead
$ bzr init-repo --no-trees .
$ bzr branch lp:loggerhead

$ mkdir ~/Projects/loggerhead
$ cd ~/Projects/loggerhead
$ bzr checkout --lightweight ~/Projects/repos/loggerhead/loggerhead
$ bzr checkout --lightweight ~/Projects/repos/loggerhead/feature-branch

[/home/rockstar/Projects]
cbranch_target = /home/rockstar/Projects/repos
cbranch_target:policy = appendpath

[ALIASES]
cbranch = cbranch --lightweight

Martin Albisetti and I have just hosted a session for Ubuntu Developer Week entitled "Launchpad and Bazaar : How to do it" The logs from this session can be found here. Below are the (now cleaned up) notes that I wrote down while preparing for it.

I do a lot of code review in Launchpad, use a lot of the code features, and have worked out some pretty good methods of making this simple and easy to work with. I thought, in lieu of my last post, and the ones I'm planning for the near future, it'd be good to detail some of the things that I do to make my workflow.

Launchpad's web UI is slow. I'll admit it. We're working on doing some really great things to speed it up, but frankly, all web applications are. You've got to load pages, parse javascript, etc. In fact, most things you shouldn't even have to wait around for. They are things that should require minimal attention for much of the time, and often things that are "fire and forget."

So let's build off the config settings I've already blogged about. If you haven't read that article yet, I highly suggest you go back and read it, or you're gonna get really confused really quick.

[/home/rockstar/Projects/repos]
push_location = lp:~rockstar/
push_location:policy = appendpath
public_branch = lp:~rockstar/
public_branch:policy = appendpath
submit_to = merge@code.launchpad.net

# Entertainer
[/home/rockstar/Projects/repos/entertainer]
submit_branch = lp:entertainer

mail_client = evolution

vote needs_fixing

vote approve
status approved

Many of Bazaar's dirty little secrets are hidden away in options you can set in ~/.bazaar/bazaar.conf and ~/.bazaar/locations.conf. Here are some fun things to configure to streamline your hacking with Launchpad and with other projects.

First, some background. I have a rather detailed and involved setup and workflow (which I'll detail later), so I'm going to do my best to make this as simple as possible. For the sake of this example, I'm going to lay out my folders this way:

~/
~/Projects
~/Projects/bzr
~/Projects/bzr/bzr.dev
~/Projects/bzr/foo
~/Projects/bzr/bar
~/Projects/bzr/baz
~/Projects/entertainer
~/Projects/entertainer/entertainer
~/Projects/+junk
~/Projects/private
~/Projects/private/ironlion

So I have put all my branches into a ~/Projects directory, inside a dir each for various projects I work on that are hosted on Launchpad(bzr and Entertainer for the sake of this example). I also have two other folders, one called +junk (for junk branches), a folder called private which, as you may have guessed, will be for things I don't push to Launchpad (like, say, for instance, the source for this blog, which contains db passwords all sorts of fun info... :)

To start out, let's look at my ~/.bazaar/bazaar.conf:

[DEFAULT]
email = Paul Hummer <paul@myemaildomain.com>
create_signatures = always
gpg_signing_command = /usr/bin/gpg
launchpad_username = rockstar

This where you put all the things about your general use of bzr. The email line will usually get set by doing bzr whoami which you should generally run the first time you run bzr, so that bzr knows your name and your email address. If you've ever seen your revisions on Launchpad saying something like rockstar <rockstar@megatron> it's probably because you haven't set your email config line, and so it's taking your user name and host name of the system you're working on (in this case, my system's name is megatron). I've also set my launchpad username. This is also important, and would get set when doing bzr launchpad-login rockstar Confused yet? If so, just skip down to the next block. create_signatures and gpg_signing_command are both to allow me to sign my revisions.

[ALIASES]
cbranch = cbranch --lightweight
ci = commit --strict
diff = diff --diff-options -p
diff-thread = cdiff -r thread:
ll = log --line -r-10..-1
lpsend = send --no-bundle
recentlog = log -r-20..-1 --short
sdiff = cdiff -r submit:
st = status --short
unpushed = missing --mine-only :push

These are my aliases. Think of them like shell aliases. The details you don't have to worry about too much, but when find yourself running the same commands over and over, add them to your aliases.

locations.conf is where all the fun happens. It's what tells bzr, based on the location of the branch, where to push, where to submit, etc. So let's start with a generic blanket statement that'll be used for all projects pushed to Launchpad. So let's start with:

[/home/rockstar/Projects]
push_location = lp:~rockstar/
push_location:policy = appendpath
public_branch = lp:~rockstar/
public_branch:policy = appendpath

The secret here is in the appendpath. Basically, bzr looks at the relationship of the current branch, say ~/Projects/entertainer/entertainer to this config section, and, using the appendpath policy, decides it needs to be pushed to lp:/~rockstar/entertainer/entertainer Hooray! Now, if I create a new branch at ~/Projects/entertainer/fix-bug-123465 and just call bzr push, bzr is smart enough to push it to lp:~rockstar/entertainer/fix-bug-123456 This even works with junk branches (branches that aren't attached to a project), provided you just put your branch in the +junk folder.

But wait! What if I don't want to push to Launchpad? I first ask "Why don't you? It's so great!" :) As locations.conf stands now, if you put something in your private area, Launchpad is going to tell you there is no project named private when yo utry to push. Well, let's fix that.

[/home/rockstar/Projects/private]
push_location = bzr+ssh://bzr.eventuallyanyway.com/code/
push_location:policy = appendpath
public_branch = bzr+ssh://bzr.eventuallyanyway.com/code/
public_branch:policy = appendpath

As you can see, I push my private branches to bzr.eventuallyanyway.com/code. It uses the same tricks as I showed before, so the same idea can be assumed.

It's important that I point out that there's no order required in how these config sections get put into locations.conf because bzr is smart enough to find the most specific config and use it.

This concludes this session of bzr-lp hackery. Comments welcome.