====== 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:
  * Easy web-interface for external users/reporters
  * E-mail interface for the developers (both ways)
  * RPC-interface (or similar) for scripted behaviours
  * Code integration/hosting (optional as Mercurial has a decent web interface on its own)
  * Task (feature requests, long term issues and so forth) management
  * Free of charge, or open source so we can host it ourselfs

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
  * Trac
  * Roundup


==== Launchpad.net ====
Metainfo:
Launchpad is the bugtracking-software used by [[www.ubuntu.com|Ubuntu]], a linux distribution driven by
[[www.canonical.com|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:
<code text>
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
</code>
Notice the space before "affects"!

The rest of the email-interface features are explained [[https://help.launchpad.net/BugTrackerEmailInterface|here]]

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

Python example of usage:
<code python>
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'
</code>

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 1280x800)

=== 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.
<code python>
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

</code>

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 =====
  * Google code - Main feature is code-hosting. Bugtracker is not really there yet.
  * Flyspray - Has serious performance issues, and code quality is known to be under par.
  * Request Tracker - Not really a tool that helps opening the development. Its a behemoth not fitting our needs
  * JTrac - Missing key components like email intergration and rpc interface. Has some other issues as well.