–create-prefix not needed with bazaar.launchpad.net

When outlining the use of team branches on Launchpad previously, I used the --create-prefix option when pushing the branch to sftp://bazaar.launchpad.net. This was to make sure the initial push would succeed, even if the /~username/product directory the branch would be created in didn’t exist.

To simplify things for users, we made a change to the SFTP server in the latest release, so that --create-prefix is no longer necessary. This does not affect the allowed branch directories though: the structure is used to associate the branches with products, and decide who can write to the branches.

Another change included in the rollout is the ability to rename branches and reassign them to different owners through the web interface. So for instance, you can give ownership of a personal branch to a team your project grows to multiple developers. This should be used sparingly, since it will change the published branch URLs which can confuse people using your branch.

Ubuntu Bugzilla Migration Comment Cleanup

Earlier in the year, we migrated the bugs from bugzilla.ubuntu.com over to Launchpad. This process involved changes to the bug numbers, since the Launchpad is used for more than just Ubuntu and already had a number of bugs reported in the system.

People often refer to other bugs in comments, which both Bugzilla and Launchpad conveniently turn into links. The changed bug numbers meant that the bug references in the comments ended up pointing to the wrong bugs. The bug import was done one bug at a time, so if bug A referred to bug B but bug B hadn’t been imported by the time we were importing bug A, then we wouldn’t know what bug number it should be referring to.

The solution we used was to just insert a link to the bug watch URL (e.g. https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/$BUGID), which allowed people to find the referenced bug, but was a bit ugly.

Today we ran a fixup script to remove these bug watch URLs from comments and rewrite the old Bugzilla bug numbers to the current Launchpad bug numbers. This cleans up the old imported bugs a bit so they fit in better with the bugs entered directly into Launchpad.

Shared Branches using Bazaar and Launchpad

Earlier, David Allouche
described how to
host Bazaar branches on Launchpad
. At the end, he alluded to the
ability to create branches that can be committed to by anyone on a
team. I’ll describe how this works here.

Launchpad Teams

Launchpad allows people to organise themseleves into teams. Most
of the things people can do in Launchpad can also be done by teams,
including owning branches.

You can create a new team at the following page:

https://launchpad.net/people/+newteam

There are three different membership policies you can choose
from:

  • Open: anyone can join. Choosing this sort of team
    effectively gives everyone write access to branches owned by the
    team.
  • Moderated: new memberships must be approved by one of the
    administrators (this is the default policy). This makes it easy for
    people to request commit access to the branch while still requiring
    approval from a team administrator..
  • Restricted: new members can only be added by the team
    administrators. This is appropriate if new members shouldn’t be able
    to propose themselves normally.

Once the team has been created, members of the team can create the
branches.

Uploading a Team Owned Branch

Now that you are a member of a team, you can upload branches to
that team’s directory on bazaar.launchpad.net. This is done
in the same way as uploading personal branches described in David’s
article
:

cd branchdir
bzr push --create-prefix sftp://bazaar.launchpad.net/~teamname/product/branchname

When the command completes, the team owned branch will have been
created. Now you can treat this branch like a personal branch, but
once someone else pushes a commit to the branch, “bzr push
will tell you that the branch has diverged, and not let you push your
changes until you merge them to your branch.

An alternative model is to use checkouts, which provide a workflow
closer to CVS and Subversion without losing Bazaar’s ability to work
while disconnected.

Bazaar Checkouts

A Bazaar checkout is a local working copy bound to a remote branch
such that changes are committed to the remote location. The remote
branch data is also cached locally to speed up local operations and
allow you to work while disconnected from the network. A checkout of
the previously created team branch can be created with the following
command:

bzr checkout sftp://bazaar.launchpad.net/~teamname/product/branchname team-branch
cd team-branch

Alternatively if you still have the local branch used to create
the team branch, it can be converted to a checkout with the “bzr
bind
” command:

cd branchdir
bzr bind sftp://bazaar.launchpad.net/~teamname/product/branchname

You can then make commits to the checkout as you would with any
other branch, provided the checkout is up to date with the remote
branch. If another team member has committed to the branch in the
mean time though, you will be prompted to update your checkout to the
head of the latest version of the remote branch.

If this happens, the checkout can be updated by issuing the
bzr update” command. You can then retry the commit, after
fixing any conflicts that are reported.

Disconnected Operation with Checkouts

If you are disconnected from the network, it will be impossible to
publish your changes to the remote branch so running the “bzr
commit
” command on the checkout will fail.

To handle this situation, Bazaar lets you make local commits in
your checkout. This is performed with the “bzr commit
--local
” command. You can treat these commits just like regular
commits and get diffs between them, etc.

When you are connected to the network again, run “bzr
update
“. This will pull in any changes made to the remote branch
and turn your local commits into a pending merge. After fixing any
conflicts (if there are any), running “bzr commit” will
publish the changes to the remote branch for the world to see.

Feature Branches

If you are developing a feature that is not yet appropriate to
check into the mainline team branch, the checkout workflow may not be
convenient. In this case, it may make sense to create a personal
branch to do the work and then merge the changes later on.

You can create a new branch using the “bzr branch
command. Since the checkout made previously contains full history
data we can branch from it directly, which saves saves downloading the
branch again:

bzr branch checkoutdir mybranch

If you want to make this branch available to others, it can be
published to bazaar.launchpad.net as described in David’s
original article.

Merging your branch into the checkout is the same as merging into
any other Bazaar branch:

bzr update
bzr merge mybranch
# resolve any conflicts that may be reported
bzr commit

Once the commit completes, the changes will be available on the
team branch.

Conclusion

Without much trouble, you can create a shared mainline branch with Bazaar and Launchpad and use it in a way familiar to Subversion users. With one extra command you can extend the familiar model to allow commits while disconnected, providing the power of distributed revision control when you need it.

Launchpad enterered into Python bug tracker competition

The Python developers have been looking for a new bug tracker, and essentially put out a tender for people interested in providing a bug tracker. Recently I have been working on getting Launchpad‘s entry ready, which mainly involved working on SourceForge import.

The entry is now up, and our demonstration server is up and running with a snapshot of the Python bug tracker data.

As a side effect of this, we’ve got fairly good SourceForge tracker import support now, which we should be able to use if other projects want to switch away from SF.

pygpgme 0.1 released

Back in January I started working on a new Python wrapper for the GPGME library. I recently put out the first release:

http://cheeseshop.python.org/pypi/pygpgme/0.1

This library allows you to encrypt, decrypt, sign and verify messages in the OpenPGP format, using gpg as the backend. In general, it stays fairly close to the C API with the following changes:

  • Represent C structures as Python classes where appropriate (e.g. contexts, keys, etc). Operations on those data types are converted to methods.
  • The gpgme_data_t type is not exposed directly. Instead, any Python object that looks like a file object can be passed (including StringIO objects).
  • In cases where there are gpgme_op_XXXX() and gpgme_op_XXXX_result() function pairs, these have been replaced by a single gpgme.Context.XXXX() method. Errors are returned in the exception where appropriate.
  • No explicit memory management. As expected for a Python module, memory management is automatic.

The module also releases the global interpreter lock over calls that fork gpg subprocesses. This should make the module multithread friendly.

This code is being used inside Launchpad to verify incoming email and help manage users’ PGP public keys.

In other news, gnome-gpg 0.4 made it into dapper, so users of the next Ubuntu release can see the improvements.

London

I’ve been in London for a bit over a week now at the Launchpad sprint. We’ve been staying in a hotel near the Excel exhibition centre in Docklands, which has a nice view of the docs and you can see the planes landing at the airport out the windows of the conference rooms.

I met up with James Bromberger (one of the two main organisers of linux.conf.au 2003) on Thursday, which is the first time I’ve seen him since he left for the UK after the conference.

There has been a lot of interesting stuff going on so far, some of which is already live on the production site now. Expect to see better integration with the bzr branch management features in the future.

Bugzilla to Malone Migration

The Bugzilla migration on Friday went quite well, so we’ve now got all the old Ubuntu bug reports in Launchpad. Before the migration, we were up to bug #6760. Now that the migration is complete, there are more than 28000 bugs in the system. Here are some quick points to help with the transition:

  • All bugzilla.ubuntu.com accounts were migrated to Launchpad accounts with a few caveats:
    1. If you already had a Launchpad account with your bugzilla email address associated with it, then the existing Launchpad account was used.
    2. No passwords were migrated from Bugzilla, due to differences in the method of storing them. You can set the password on the account at https://launchpad.net/+forgottenpassword.
    3. If you had a Launchpad account but used a different email to the one on your Bugzilla account, then you now have two Launchpad accounts. You can merge the two accounts at https://launchpad.net/people/+requestmerge.
  • If you have a bugzilla.ubuntu.com bug number, you can find the corresponding Launchpad bug number with the following URL:

    http://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/$BUGZILLA_ID

    This will redirect to the Launchpad bug watching that bugzilla bug. This URL can easily be used to make a Firefox keyword bookmark.

  • You can file bugs on Ubuntu at https://launchpad.net/distros/ubuntu/+filebug. Note that the form expects a source package name rather than a binary package name. If you only have a binary package name, you can use the following command to find the source package name:

    apt-cache show $packagename | grep ^Source:

    We’ll make it easier to enter bugs when you only know the binary package name in the future.

  • The Launchpad data model for bugs differs from Bugzilla in that a single bug can be targetted at multiple packages or products (internally, we call these bug tasks). To change information about a bug task (source package name, assignee, status, priority, severity, etc), you must first click on the bug target in the “fix requested in” table at the top of the bug page.

There are still a few issues that need to be ironed out. The mailing lists subscribed to most Ubuntu bugs are not yet properly configured to accept mail from Launchpad, so result in “held for moderation” messages. These issues should get fixed shortly.