Table of Contents

Migration to a new bugtracking system from Sourceforge

In later times NAV developers and users have been complaining about the speed and feel of Sourceforge.net as a tool in the development. Reporting bugs and issues should be extremly easy and fast, as this causes _more_ reports, and more information is allways good.

As for features we want this should the trick:

Assignment of tasks, statuses and such is considered a must, so its not mentioned in the list.

I have selected the following systems for reviewing (please notify me if I've missed any other decent ones):

Launchpad.net

Metainfo: Launchpad is the bugtracking-software used by Ubuntu, a linux distribution driven by Canonical. Its well tested and under active development as ubuntu grows. Other major projects that use launchpad includes mysql, inkscape and bazaar.

Webinterface:

Reporting bugs

Including login reporting a bug takes three clicks (unless launchpad thinks its a duplicate bug, then its four). The pages are very snappy, and the whole process shouldn't take more than a minute, depending on the complexity and the reporters writing speed.

Managing bugs

From the bugs panel in launchpad, searching for a bug, and changing its status is 5 mouse clicks, which is quite acceptable. As a side note; every edit and change in launchpad is logged and revertable, so we get complete histories for each bug.

Merging bugs

Not supported

Email interface

Launchpad offers a webinterface that bases it security upon gpg-signed emails. The signature must be registred in the launchpad system. This is done easily from their web interface. A typical bug-reporting email would look something like this:

From: Kristian Klette <kristian.klette@uninett.no>
Subject: Netmap crashes on solaris
To: new@bugs.launchpad.net
 
The netmap crashes on my solaris box.
 
 affects nav

Notice the space before “affects”!

The rest of the email-interface features are explained here

RPC interface

Launchpad offers a rpc-api through xmlrpc.launchpad.net/bugs/

Python example of usage:

from xmlrpclib import ServerProxy
 
s = ServerProxy("https://kristian.klette@uninett.no:notmyrealpassword@xmlrpc.launchpad.net/bugs/")
s.filebug(dict(
    product="nav",
    summary="Netmap crashes on solaris",
    comment="The new netmap crashes on my solaris box"))
 
>> 'http://launchpad.net/bugs/xxx'

This enables us to have easy tools on a console level for reporting bugs, and maybe in the future even have automated bug reporting on crashes from nav.

Code hosting/integration

Launchpad.net offers code-hosting of tarballs. It also supports mirroring of bzr-branches and svn-branches, but neither of these apply to us, as we use mercurial.

Task management

Task management in launchpad are provided through “blueprints”. Each blueprint has their own page, and can be assigned to people. These features seem to cover all our task-needs

Price

Launchpad.net is closed source, so we cannot make changes to how things are done ourself. The service is free of charge, and they say they have a long term goal of becoming open source.

Migration from sourceforge

The launchpad.net team does imports from sourceforge on requests. They have done this for several major projects, so they know what they are doing. An alternative is to write a small python script that parses the backup xml from sourceforge and uploads it through the rpc interface. This messes up the history though.

Trac

Trac is a multipurpose software management system written in python under the BSD lisence. Its still under active development, and has a variety of plugins available. Trac is well tested and used by many large software projects.

Web interface

Reporting bugs

For a logged in users, reporting a bug is done i 2 mouse clicks. Very nice! Trac does not check for duplicate reports though

Managing bugs

Searching for a bug, entering it and changing it is done 3 mouse clicks. Though with quite a bit of scrolling on the bug page itself on smaller screens. (Tested in 1280×800)

Mail interface

Per default Trac only has support for notification emails. Trac does however expose some of its internal api trough python, so it is possible to write a plugin for it trough /etc/aliases (RT-style). But we'd had to maintain this code ourself.

RPC interface

Trac does not have an rpc interface per default, but there is a plugin available that exposes some of the python api.

import xmlrpclib
# Connect
server = xmlrpclib.ServerProxy("https://kristian.klette@uninett.no:notmyrealpassword@localhost/trac-dev/login/xmlrpc")
 
# Report a bug
ticketid = server.ticket.create("My summary", "A description of the problem")
 
# base64 encode traceback
import base64
trackeback = base64.b64encode(get_traceback())
 
# Add traceback to ticket
server.ticket.putAttachment(ticketid, "traceback.log", "Traceback of the error", traceback)	
 
print "Created ticket", ticketid

The api it self is quite nice actually, though poorly documented. A rough api-coverage is given at www.track-hacks.org, but only to authenticated users.

Code hosting/integration

Trac support code integration of mercurial branches trough a plugin. The plugin is available in debian, so shouldn't be too hard to get going properly.

Task management

Trac differentiates tasks from bugs throug bug-types (one can mark something as a bug, feature request, todo and so forth)

Price/Licensing

Newer Trac releases are released under a modified BSD license

Migration from sourceforge.net

Trac includes a contrib-script that takes a backup xml dump from sf.net and uploads it to the instance. So migration should be quite painless.

Roundup

Roundup was tested for a day. It was discontinued because the share amount of time needed to configure and customize it for our needs is just staggering. The tracker only knows about issues, and have silly way of doing descriptions and so fort (everything is a comment). The tracker itself has its own webserver and it doesnt allow usage of another. If you want to access it trough apache you have to use mod_proxy.

Comparison table

Bugtracker Speed clicks/reporting clicks/status clicks/merge mail-interface rpc-interface code integration task management price/license
Launchpad 7 3 4 - yes yes no (bzr only) yes free
Trac 8 2 3 - no yes (plugin) yes (plugin) yes (not seperate) BSD

Conclusion

The choice really just narrows down to wheter we'd like to host the tools ourselfs. Hosting our own trac-instance is a good thing because we get complete control. The downside is that some actions must be done through the CLI, and not all developers have access to metnav. This undermines NAV being an open project. Not hosting it ourselfs provides to major benefits. First and most important is the fact that we dont have to maintain or do anything regarding the administration, or development on the codebase it self, nor the hardware its running on. Secondly it may give us some publicity and further help us in our goal in becoming more open in our development. As another factor in this is the both ways support for emails on launchpad - if we want this in trac, we are going to have to make it ourselfs, taking even more time away from solving the tasks that we are supposed to be solving.

Because of these reasons, I suggest as of today that we switch from sourceforge.net to launchpad

Bugtrackers not tested, but evaluated