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/03 10:17]
klette added some more on trac
bugtracker [2008/07/04 20:09] (current)
klette Eval of JTrac
Line 21: Line 21:
   * Launchpad.net   * Launchpad.net
   * Trac   * Trac
-  * Mantis+  * Roundup
  
  
Line 87: 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 106: Line 111:
  
 === RPC interface === === RPC interface ===
-Trac does not have an rpc interface per default, but there is a plugin available that exposes the python api. +Trac does not have an rpc interface per default, but there is a plugin available that exposes ​some of the python api.
-It works by sending a list of functions and their parameters to the rpc. +
-ie+
 <code python> <code python>
-send(( +import xmlrpclib 
-    (add-bug(param1, param2param3)), +# Connect 
-    (close-bug(param1param2param3)), +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>​ </​code>​
-(not a real api calls) 
  
-This is very flexible and allows us to do lots a crazy stuff, but it opens a security issue, and is hard to +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.
-use for anything other than internal use.+
  
 === Code hosting/​integration === === Code hosting/​integration ===
Line 129: Line 142:
 === Price/​Licensing === === Price/​Licensing ===
 Newer Trac releases are released under a modified BSD license 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 ====
- +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 
-=== Web interface === +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.
-== Reporting bugs == +
-== Managing bugs == +
  
 ===== Comparison table ===== ===== Comparison table =====
 ^ Bugtracker ^ Speed ^ clicks/​reporting ^ clicks/​status ^ clicks/​merge ^ mail-interface ^ rpc-interface ^ code integration ^ task management ^ price/​license ^ ^ 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 | | Launchpad ​ | 7 | 3 | 4 | - | yes | yes | no (bzr only) | yes | free |
-| Trac       | 8 | 2 | 3 | - | no  | no  | yes (plugin) ​ | yes (not seperate) | BSD | +| Trac       | 8 | 2 | 3 | - | no  | yes (plugin) ​ | yes (plugin) ​ | yes (not seperate) | BSD | 
-| Roundup ​   | 9 | | - | - | yes | yes | no            | yes (everything ​is a task) | partial copyleft |+ 
 +===== 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.1215080259.txt.gz · Last modified: 2008/07/03 10:17 by klette