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):
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.
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.
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.
Not supported
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
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.
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 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
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.
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 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.
For a logged in users, reporting a bug is done i 2 mouse clicks. Very nice! Trac does not check for duplicate reports though
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)
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.
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.
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.
Trac differentiates tasks from bugs throug bug-types (one can mark something as a bug, feature request, todo and so forth)
Newer Trac releases are released under a modified BSD license
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 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.
| 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 |
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