About two and a half years ago I wrote about how the MariaDB project moved bug reporting from Launchpad to JIRA. Every now and then I get contacted about how it was done and whether I would be willing to share the tools used for doing it and of course I’ve done that. Especially in one occasion the scripts were even further developed by one company that was in the process of doing exactly the same, i.e. moving bugs from Launchpad to JIRA. Thanks for the enhancements Philip Colmer from Linaro!

In Launchpad there isn’t a readymade tool for exporting bugs and I didn’t find any 3rd party tools for doing it. Launchpad however has an API through which most (if not all) information in Launchpad can be retrieved. Launchpad has made a library available in Python making use of this API.

By using the Launchpad Python API, I wrote a Python script LaunchpadBugs.py that pulls out bug information from Launchpad and creates an XML document for each bug. If the bug includes attachments these are also downloaded and named in a way that they can be connected to the XML.

It would, of course, be nice if the bunch of XML files and attachments that you end up with after running the Python script could be uploaded directly into a JIRA instance. Unfortunately this is not possible, unless it has been added recently, and instead a separate format is needed. According to my investigations, JIRA supports importing information best if it’s in CSV (comma separated values) format. That leads to converting a bunch of XML files to a CSV file. The CSV file can include links to the attachments.

I’ve done quite a lot of C# programming in the past and still had the way of dealing with XML in C# in my head, so I chose to do the XML to CSV conversion in C# in a Windows command line application. You’ll find the application named JiraCSV in the Github repository mentioned below.

The scripts described above have been useful for those that have reached out explicitly asking for a copy of them, but maybe the interest is broader. To initially get to the point where migration was successful it took a lot of trials to correct the data, add missing data, change the XML or CSV structure, and so on to get everything accepted by JIRA. I hope that by now sharing these scripts people will save a significant amount of time. That’s why I’ve decided to put them up on Github so that anyone interested in them can pick them up and make use of them or even improve them further. You can find them at https://github.com/rasmushoj/LP2JIRA.

It is not a secret that we’ve been kicking the tires and playing with JIRA for project management. After using it since the beginning of the year most of us like the feel of it and we’ve decided that it makes sense to start using it more.

As you know, the MariaDB project has many fragmented resources. We report bugs in Launchpad. We store our plans in worklog. We’ve never used the Launchpad Blueprint feature for this very reason. We don’t use Launchpad Answers because we have the Knowledgebase.

With this move to hosted JIRA (yes, this is an important link: http://mariadb.org/jira) we can report bugs, have future plans, and also give users a roadmap which is pretty cool. One nifty feature is that in the past two releases, we had a roadmap and we didn’t slip in terms of a schedule. We had on time releases and that’s awesome!

So what does this mean for you? To report bugs, you will now do so on JIRA. To make feature requests and talk about our future plans, you will also now use JIRA.

We plan to deprecate Worklog and Launchpad bugs by 30 June 2012. Launchpad will however continue to host the source code for MariaDB.

What will happen to bugs already reported on Launchpad? We have migration scripts ready for this and when we press the button bug reports will nicely migrate over to JIRA. After that is done we’ll place a notification on the MariaDB bugs page in Launchpad about reporting new bugs in JIRA.

What will happen to feature requests and ideas already in worklog? Worklog will be put into a read-only mode and there will be notifications about the move to JIRA. Whenever needed we’ll copy & paste worklog items into JIRA.

What does it mean to the openness of the MariaDB project? It’s not affected at all. The MariaDB project will remain an open community friendly project and as a bonus it will be easier to follow what is going on in the project since you don’t have to jump between several tools to get the complete picture.

The consolidation to JIRA provides the means to report and track project status easier than before, which allows the MariaDB team, community members and other to better coordinate and prioritize work.

As a side note, JIRA (and other software by Atlassian) has sometimes been criticized in the open source world because of its commercial nature and many are unaware of the fact that Atlassian do offer a free Open Source Project License to open source projects, which is what is being used with MariaDB.

As another side note, I’m not going to dive into comparing features in e.g. Launchpad with features in JIRA. I do know it would be possible to use blueprints for feature specifications etc. in Launchpad. The most important aspect in my mind is that you pick a tool that you like the feel of, has the features you need and tightens collaboration between developers, project managers, community members and other persons involved in the project.

In short, this is all about three project tools becoming one.

If you work with bazaar, you have seen its URIs. You can find the complete list is in the bzr help urlspec. Although I commonly use only a subset of that, like bzr+ssh://bazaar.launchpad.net/~maria-captains/maria/5.2-serg/ and http://bazaar.launchpad.net/%2Bbranch/mysql-server/5.5/.

In addition I often use Launchpad aliases, such as lp:~maria-captains/maria/5.3-serg/, lp:maria/5.3, and lp:869001.

And finally, there are common abbreviations that we have used in MySQL, and others that we use in MariaDB, for example bug#12345 and wl#90.

What’s annoying, I need to remember that wl#90 corresponds to http://askmonty.org/worklog/?tid=90 and type the latter in the location bar of the browser, when I want to look this task up. And lp:869001 is, for my browser, https://bugs.launchpad.net/bugs/869001. Similarly, every other URL above, has its browser-friendly evil twin. It’s evil, because I have to remember it!

Now, Firefox tries to help, to a certain extent. It supports so-called keywords — short aliases for bookmarks. Create a bookmark for https://bugs.launchpad.net/bugs/%s and in the Keyword field enter lp. Now you can type in the location bar lp 869001 (with a space) and Firefox will expand it into a complete url https://bugs.launchpad.net/bugs/869001. Quite handy. And I’ve used it for a few years. Still it annoyed me, that I had to rewrite the abbreviations manually, put spaces, remove colons, and so on. And at last it annoyed me to a degree where I wrote a Firefox plugin!
Continue reading