User Tools

Site Tools


bugtracker

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
bugtracker [2008/07/01 10:29]
klette
bugtracker [2008/07/04 20:09] (current)
klette Eval of JTrac
Line 21: Line 21:
   * Launchpad.net   * Launchpad.net
   * Trac   * Trac
-  * Mantis+  * Roundup
  
  
Line 37: Line 37:
 From the bugs panel in launchpad, searching for a bug, and changing its status is 5 mouse clicks, which is quite acceptable. 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. 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 === === Email interface ===
Line 73: Line 76:
 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. 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 ===+=== Code hosting/​integration ​===
 Launchpad.net offers code-hosting of tarballs. It also supports mirroring of bzr-branches and svn-branches,​ but neither of these 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. apply to us, as we use mercurial.
Line 84: Line 87:
 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 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. 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 ====
Line 98: Line 106:
 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) 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.
bugtracker.1214908161.txt.gz ยท Last modified: 2008/07/01 10:29 by klette