Moving from Bugzilla to Launchpad

One of the things that was discussed at UBZ was moving Ubuntu’s bug tracking over to Launchpad. The current situation sees bugs in main being filed in bugzilla while bugs in universe go in Launchpad. Putting all the bugs in Launchpad is an improvement, since users only need to go to one system to file bugs.

I wrote the majority of the conversion script before the conference, but made a few important improvements at the conference after discussions with some of the developers. Since the bug tracking system is probably of interest to people who weren’t at the conf, I’ll outline some of the details of the conversion below:

  • We are only migrating the open bugs — the existing bugzilla will remain available to read those bugs though.
  • Any bugzilla user account associated with an open bug (asignee, reporter, cc, qa contact or commenter) will be imported into Launchpad. If you already have a Launchpad account but use a different email for your bugzilla account, you have the following options:
    1. Add your bugzilla email to your Launchpad account.
    2. In bugzilla, change your email to one of the addresses registered to your Launchpad account.
    3. After the migration, merge the extra account into your existing account.

    Note that passwords are not migrated, because Launchpad uses a different password hashing algorithm to Bugzilla

  • All comments and attachments are imported.
  • Bugs are filed against the appropriate package under the “Ubuntu” distribution in Launchpad.
  • A bug watch is created, pointing at the original Bugzilla bug, so you can see any information not migrated.
  • If the bug was marked UPSTREAM and a bug tracker URL is included in the bugzilla URL field, then we attempt to create a bug task against the upstream product and link it to the remote bug. This depends on the upstream product existing and being linked to the package, so doesn’t always succeed. This feature was implemented to keep Sebastien happy, 68% of the UPSTREAM bugs are assigned to him.
  • Some of the bugzilla bugs are actually imported from debbugs. For these bugs, a bug task will be filed against Debian linked to the appropriate debbugs bug.

There are a few other things that need completing on the production Launchpad server before we can do the migration, but we should have a test import done on the staging server tomorrow some time.

Version control discussion on the Python list

The Python developers have been discussing a migration off CVS on the python-dev mailing list. During the discussion, Bazaar-NG was mentioned. A few posts of note:

I’m going to have to play around with bzr a bit more, but it looks very nice (and should require less typing than baz …)

Version Control Workflow

Havoc: we are looking at ways to better integrate version control in Launchpad. There are many areas that could benefit from better use of version control, but I’ll focus on bug tracking since you mentioned it.

Take the attachment handling in Bugzilla, for instance. In non-ancient versions, you can attach statuses to attachments such as “obsolete” (which has some special handling in the UI — striking out obsolete attachments and making it easy to mark attachments as obsolete when uploading a new attachment). This makes it easy to track and manage a sequence of patches as a fix for a bug is developed (bug 118372 is a metacity bug with such a chain of patches).

If you look at this from a version control perspective, this sequence of patches forms a branch off the mainline of the software, where each newly attached patch is a new revision. The main differences being:

  • No explicit indication of what the patch was made against (code base or revision), or what options were used to create the patch.
  • No linkage between successive patches (can be a bit confusing if multiple patch series are attached to the same bug report).

So why not just use real version control to manage patches in the bug tracker? The big reason for projects using CVS or Subversion is that only authenticated users can create branches in the repository, and you don’t want to require contributors to ask permission before submitting fixes.

So this is an area where a distributed version control system can help: anyone can make a branch, so potential contributors don’t need permission to begin working on a bug. This also has the benefit that the contributors get access to the same tools as the developers (which is also helpful if they ever become a regular developer).

Now if you combine this with history sensitive merging and tell the bug tracker what the mainline branches of the products are, you can do some useful things:

  • Try and merge the changes from the bug fix branch onto the mainline, and see if it merges cleanly. This can tell a developer at a glance whether the patch has bitrotted. This could also be used to produce an up to date diff to the mainline, which can aid review of the changes.
  • Check if the bug fix branch has been merged into the mainline. No need for developers to manually flag the attachment as such.

We discussed some of these features in the context of Launchpad at the recent Brazil meeting.

Back from Brazil

I got back from the Launchpad sprint in São Carlos on Tuesday afternoon. It was hard work, but a lot of work got done. Launchpad is really coming together now, and will become even better as some of the things discussed at the sprint get implemented.

One of the things discussed was to formalise some of the development workflow we’ve been using to develop Launchpad inside Launchpad itself so that it will be usable by other projects.

I really enjoyed the time in Brazil. The food and fruit juices were great (especially the ones made from native fruits like Açaí).

At the end of the second week, Mark flew us up to Rio de Janeiro for the weekend on his jet:

Canonical One
Inside Canonical One

We took a cable car up Corcovado mountain to see the Cristo Redentor statue. There was a great view from the top.

Cristo Redentor
Rio de Janeiro from Corcovado

Since I was leaving that weekend, I didn’t fly back to São Carlos with everyone else. Instead Kiko got a local travel agent to book me a flight directly to São Paulo, so that I could catch my international flight.

Unfortunately, when I went to the Varig ticket counter to pay for the ticket there was no record of the booking, which was bad.

However, I was able to buy a ticket on the flight anyway (which was due to leave in an hour), which was good. I even ended up paying less for the ticket than I expected.

Once I got through security, I found the flight had been delayed, which was bad. After the departure time changing about 3 times, we ended up boarding about an hour after the original listed departure time. This happened to coincide with the listed departure time of the next Varig flight to São Paulo (which had the same gate listed too), causing some confusion.

They served chocolate fondue on the flight, which was nice.

When I reached São Paulo, it turned out that my checked luggage hadn’t, which was bad. I filled out a lost luggage form, and the staff said they’d try to get my bag to the international airport in time for my next flight if it turned up.

At the Buenos Aires and Auckland airports, I tried to find out whether my bags had made it onto the flight. The conversations would go something like this:

me: Hi, my bag got lost on a previous flight and I want to know whether it made it onto my current flight. Here is the lost luggage form with the bag tag number.
them: do you have a bag tag?
me: no, they took the tag when processing the lost luggage report.
them: well, I can’t track the bag without the bag tag. You should have kept the tag.
me:

It was almost the same in Sydney, except the guy at the desk took a look at the form and realised that it had a bag tag number on it (the thing they wanted the bag tag for), and found that the bag had been put on my flight. Sure enough, it turned up on the carousel.

The rest of the trip was fairly uneventful, which was nice.