launchpadblog

Earlier today, Graham wrote about the Trac to Launchpad migrator.

In his post, Graham mentioned the XML schema we use as an interchange format when bringing a project’s bug history from elsewhere. It’s something that we knocked together to help projects when they move from other bug trackers. Although it’s still something that’s in development, you can use it as an intermediate format if you’re planning to import your project’s bug history from another tracker.

You can find the format, and also subscribe to get any updates if we make changes, over on the help page.

Greetings, readers!

For a while now I’ve been the Launchpad developer in charge of helping users of other bug trackers migrate their projects to Launchpad. We do this reasonably regularly for users of Trac, SourceForge and Bugzilla, and we’re always open to helping people migrate from other solutions should they wish to.

Several months back, the Elisa project migrated from Trac to Launchpad. In doing so, they wrote a script to take their Trac database and convert it to the Launchpad bug interchange format, which is an XML schema that we use for bug imports (you give us an XML document containing your bugs that conforms to the interchange format schema and we can then import it into Launchpad for you).

More recently, we realised that we were getting quite a few requests from Trac users for help with migration. We went back to the Elisa developers and asked if they’d be willing to let us have their migration tool under the GPL so that we could share it with everyone. They kindly said yes, passed the code to us under GPLv3, and yesterday I made it available on Launchpad as the Trac to Launchpad Migrator project.

It’s a bit rough around the edges at the moment and needs some documentation, but more than anything else it needs people to test it and use it so that we can make migrating from Trac to Launchpad as smooth as possible.

Update: Matthew’s written a blog post about our bug import format.

There’s now more Ajaxy goodness on bug pages: in-line bug tag editing and also in-line subscriptions.

Both are simple actions that I always wished could happen without a page reload.

Have a look at the video I made or give it a go over on Launchpad’s staging environment without affecting real bug data.

View this video in Ogg Theora format.

In the latest release of the Launchpad bug tracker, we have introduced a new feature: official bug tags. Tags blessed by the project team as official display using a darker colour on the bug page, and are placed prominently at the top of the tags list on project pages. Users can still add tags that are not endorsed by the project as official, but they are encouraged to use official tags where possible.

Tags are a great way to group bugs together, and their free-form nature allows all users participating in bug tracking to invent new and interesting ways to categorize bugs. Many projects, after working with bugs for a while, discover that some tags fit their process. That using a certain tag is particularly helpful, or even required, to facilitate a regular routine. With official tags, the project team can indicate to the community what tags are encouraged, and use that to steer users away from duplication and ad-hoc invention and towards standardization.

To decide which tags are official for your project, go to the project’s bugs page and click the link at the bottom of the tags list. The management screen has two columns. On the left, highlighted in yellow, is the list of official tags. The list on the right is of all tags currently in use. To make some tags official, select them in the right-hand column and click the left arrow button. The tags now appearing in the list on the left hand are official ones. You can also add a new tag to the list of official tags. When you’re done, click the Save button to record your changes. As an alternative, you can set the official tags for your project using the web service API.

We hope that official tags will help projects become better at tracking bugs consistently. We sure waited for this as Launchpad users, because until now we used to enforce the use of official tags, documented on the wiki, manually. Future work will expand and improve on this. Maris has written an amazing auto-complete widget, which will be used for tagging bugs starting in the next version and suggest to users what tags they can use as they type. We are also looking to let anyone who is a bug contact edit the official tags list, and in the longer term, also provide a way for project groups to share official tags and for allowing teams to document their chosen tags. Let us know how official tags are working for your project.

I get three kinds of email from Launchpad generally:

1. Regarding bugs I’ve reported or specifically subscribed to
2. Those assigned to a team I’m a member of
3. A very occasional question or notification about a code branch I’m subscribed to.

Of these above the second is the most voluminous and the first group is the most important. However sometimes items from group two can be important, depending on the project. Launchpad includes headers for filtering email which I’ve used in Thunderbird. I’ve not been able to create sophisticated filters in Gmail though. Until now.

In the past I just grouped all Launchpad email into a folder. This folder fills up very quickly though and it becomes a burden to identify which items need my action and decreases the effectiveness of Launchpad’s bug tracking. By creating a Gmail label for different kinds of bug email I can better attend to the messages in the proper order.

Here’s my set-up: I use Evolution to access Gmail via IMAP during the work day. Otherwise I use the Gmail web interface. I want the filtering to happen all the time so I use Gmail’s filtering, not Evolution’s. This limits our capabilities significantly. Well, maybe not … read on. 🙂

The trick is to look at the emails for something that Gmail can search on and are constant among emails you want to group by. This prevents us from using the subject or the sender or the recipient. :-/

My end result is to have a label for bugs assigned to or reported by me (including bugs I’ve subscribed to) and one label for each group or project I’ll get bug notifications from. I’m naming the labels Bugs/me, Bugs/artteam (for the Ubuntu Art Team), Bugs/website (for the Ubuntu website) and etc.

I found that all bug email is shown if I search for bugs.launchpad.net. So I’ll use it for all of my searches. I also noticed that the bottom of each email tells me why I got the message. For example, “You have received this email because you are a member of the group Ubuntu Website Editors.” That is the key. Therefore I can do a search like this:

bugs.launchpad.net "Ubuntu Website Editors"

This will show me all of the bugs for that team. I can then create a filter and put that search string in the “Has the words:” field and do a test search.

We’re set. I click next and set the rules:

"Skip the inbox" is checked
"Apply the label" -> Choose "new label" -> Name my new label Bugs/website
"Also apply filter to x conversations below" is checked

Then I click “create filter.” The interesting thing above that I’ve not mentioned yet is the label I chose. By creating a label with a / in it then when accessed via IMAP it will appear as a folder. So if I go on to create labels called Bugs/artteam and Bugs/me my IMAP client will show a “bugs” folder with three sub folders.

Speaking of Bugs/me, this filter is different than the others. The search string I used here is:

bugs.launchpad.net ("direct subscriber" | "bug assignee")

Any bug that gets assigned to me or to which I subscribe is put in the “me” folder. Because Gmail’s labels are different than true IMAP folders it means that some email threads will show up in multiple places.

I’ve only implemented this solution today so no long-term testing has been done yet, but already I’ve been able to burn through a huge backlog of bug emails simply by marking as read the bugs in entire folders and focusing my concentration on the “me” folder.

There are a few emails (about 20 in the last year or so) that didn’t get caught by the filter. A couple pre-date changes in the way Launchpad sends its emails. Others were related to “answers” and subscribed branches. The volume is so small that I foresee being able to deal with these special cases as they appear in my inbox. Maybe you have more of these special cases than I do. I hope that my explanations above are clear and you can adapt the solution to your own mailbox. Feel free to leave comments about your adaptations so that others can benefit from them.

**Bonus tip:

Do you use Gmail all the time? If so you can have your labels appear as folders that can be expanded and collapsed, just like in an IMAP email client. There are two ways to accomplish this, the simplest to install is the “Better Gmail 2” extension for Firefox, the other is the “Folders4Gmail” Greasemonkey user script. “Better Gmail” is a compilation of stand-alone Greasemonkey user scripts including the Folders4Gmail package. I decided I didn’t need most of those features and already had Greasemonkey so use only the Folders4Gmail.

Linking Launchpad bugs to upstream bugs can be hard work. You don’t necessarily know whether the bug is reported on the upstream tracker, and if you don’t know where the upstream project tracks its bugs you have to go and find out before you can file the bug and link the Launchpad bug to it.

We understand that this process can be a bit of a pain, so we’re introducing a feature that should make linking to upstream bugs a bit easier: Launchpad will now give you direct links to the bug search and filing forms in a project’s external tracker, so long as Launchpad knows the location of the project’s tracker and, if the tracker tracks more than one project, which project on the external tracker the Launchpad project refers to (so, for example, Launchpad needs to know that the Launchpad project ‘evolution’ links to the ‘Evolution’ product in the Gnome Bugzilla).

And because we know that a project maintainer shouldn’t have to go back to Launchpad and add the link to the remote project when Launchpad should be able to work it out for itself we’ve fixed that problem, too: Launchpad will check all the projects that are linked to a remote bug tracker and will try to deduce which remote project they’re linked to by looking at the bug watches that are registered against that bug tracker. Of course, this isn’t an exact science, and we’ll have to correct some of these auto-generated links manually, but hopefully it won’t take more than a few days for us to straighten out the kinks.

In order to get to remote bug tracker links, all you have to do is click Also affects project on the bug report and select the project that you want to link to. Launchpad will then offer you the links.

We’re going to be working to improve this further in the coming Launchpad development cycle, so keep your eyes on this blog for further information.

We in the Launchpad team are changing the way that we triage bugs reported against the Launchpad suite of applications.

The Wishlist importance will no longer be used. Clearly the term is not about importance. It would be nice to convert bugs into blueprints, but the two applications need to achieve feature parity before that can happen. Bugs that describe new behaviours will be tagged as a “feature”. This means that closing the bug requires more than adding missing test coverage and fixing bad logic — the feature needs specification too.

There is a distinction between the Confirmed and Triaged bug status, namely that any user can confirm a bug, but only a project member can state the bug is in the application’s code. Many bugs in the Launchpad suite of applications are implicitly in the Triaged state because the Launchpad team members have set the importance.

Changes to current bugs:

• All bugs that were Wishlist importance are now Low importance and are tagged with “feature”.
• All Confirmed bugs that had a importance of Low, Medium, or High were changed to Triaged.

We want to clarify the meaning of Critical, High, Medium, and Low by expressing their definition in practical terms. Some teams do not think Medium is distinguished from Low, so will not use it. The teams that do use Medium importance will use it to create a pool of bugs for release planning — the bugs may be escalated to High or targeted to a release without a commitment to complete them.

Critical

The bug dramatically impairs users. Users may lose their data. Users cannot complete crucial tasks. The feature is needed to encourage adoption or prevent abandonment of the project.

Synonyms: essential; now, stop everything else; must do
The work is immediately assigned to a engineer. It is his top priority to fix. Team members help the engineer to plan and do the work. The work is released as soon as it is deployable; in the case of a bug, it is released outside of the release schedule.

High

The bug prevents users from completing their tasks. The feature provides new kinds of tasks or new ways of completing tasks.

Synonyms: expected; important; now; can do; should do
The work is assigned to a engineer to be completed in the next 3 releases. The engineer may choose to do other work if he believes it is within the scope of the high priority work.

Medium

The bug is an inconvenience for many users. The feature provides new ways of completing tasks.

Synonyms: preferred; someday; last; try; want to do
The work is not scheduled, though it is intended to be completed. When the work is assigned, it may also be scheduled, but there is no commitment to complete it for the stated release. The engineer may choose to postpone the work in favour of more important work.

Low

The bug is an inconvenience to users, but it does not prevent them from completing their tasks. The feature is a convenience to users.

Synonyms: optional; someday; last; may do
The engineer may assign the work to himself while working on high priority work because the high work provides an opportunity to complete the low priority work at less cost. If the low work in any way jeopardises the high priority work, the low work is unassigned. The engineer is thus certain that the work can be fixed quickly and without difficulty. A corollary to this rule is that low work that is assigned to a engineer must be “in progress” or “fixed” states.

You can read A Practical Guide to Launchpad Bug Triage to learn more about the reasons for these changes.

If you manage bug mail using Thunderbird, you may find Fabrice Desré’s Bugmail plugin useful.

It fetches the bug’s status, and displays it in a small pane above the email body, whenever it comes across bug mail from Launchpad, Bugzilla, Trac and Flyspray. In the case of Launchpad, it fetches the bug’s status from its Atom feed.

Thanks Fabrice!

A while ago we announced the beta versions of the Launchpad plugins for Trac and Bugzilla. These allow Launchpad to sync not just bug statuses but also comments and, eventually, whole bug reports with the remote bug trackers that have them installed, bi-directionally. The practical upshot of this is that upstream projects that don’t use Launchpad for bug tracking can install one of these plugins and never again have to worry about not seeing bugs that people file using Launchpad but don’t forward upstream.

We in the Launchpad team realise, of course, that Bugzilla and Trac aren’t the only two bug trackers in the world. A project that uses Mantis, for example, may want its bug tracker to interact with Launchpad in the same way that Bugzilla and Trac now can. Unfortunately we can’t develop a plugin for every bug tracker out there as we don’t have the resources or the in-depth knowledge of those trackers’ internals necessary to be able to do so.

To make it possible for anyone to develop a plugin for any bug tracker, we’ve now opened up our Plugin API spec. The spec details all the APIs that need to be implemented for Launchpad to be able to sync bi-directionally with a remote bug tracker. It’s pretty detailed, and we’ve rolled into it our experiences in developing the Bugzilla and Trac plugins so as to make sure that new plugins don’t repeat the issues that we came across when we started interacting with the first bug trackers to install those plugins.

Once you’ve written an API plugin for your bug tracker of choice you can contact us by filing a question against Launchpad Bugs to let us know about it. We’ll then work to write the code on the Launchpad side that will interact with the API you’ve written. Once that’s done we’ll continue to work with you to iron out any bugs that we may come across.

I’m looking forward to seeing your plugins!

A few weeks ago, Matt announced the new Launchpad plugins for Bugzilla and Trac.

The plugins allow bidirectional communication between Launchpad and the remote bug trackers that have them installed. Obviously, we need to test the plugins – and that’s where we need your help.

If you know of any Trac or Bugzilla instances whose administrators might be interested in installing the requisite Launchpad plugin – or indeed if you run such a bug tracker yourself – you can find details on how to install the plugins and what you need to do to get Launchpad to work with your bugtracker on the Launchpad Help wiki:

• For Bugzilla, see http://help.launchpad.net/Bugs/BugzillaPlugin
• For Trac, see http://help.launchpad.net/Bugs/TracPlugin

So, what will installing the plugins do? Well, initially, installing one of the plugins will mean that:

• Launchpad will be able to import comments from upstream bugs which are being watched in Launchpad. If you register a bug watch against an upstream bug you’ll be able to read the conversation about that bug on Launchpad, including the comments that are made on the upstream bug tracker.
• Launchpad will be able to push comments to upstream bugs which are linked to a Launchpad bug, so if you add a comment on Launchpad in reply to a comment which was imported from an upstream bug tracker, the comment will automatically be added to the conversation on the upstream bug tracker, too. This means that users of both Launchpad and the upstream tracker can view the whole conversation about the bug without leaving their preferred environments.

Once we’re happy that the plugins are working correctly we can use them to add some even cooler functionality to Launchpad:

• Launchpad will be able to forward bugs to upstream bug trackers that have the plugin installed. Users of those bug trackers won’t have to check Launchpad for bugs registered against their project; they’ll be forwarded straight to the upstream tracker.
• If a bug watch is created against an upstream bug, Launchpad will tell the upstream bug tracker which Launchpad bug is watching it. This means that not only is there a link in Launchpad to the upstream bug, but there’s also a link in the upstream bug tracker to the Launchpad bug.

The Bugzilla plugin is licensed under the Mozilla Public License and the Trac plugin is licensed under GPLv2.

If you’ve got any questions, don’t hesitate to contact us by email at feedback@launchpad.net.