bugtracker
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| bugtracker [2008/07/03 12:18] – klette | bugtracker [2008/07/04 20:09] (current) – Eval of JTrac klette | ||
|---|---|---|---|
| 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 137: | Line 142: | ||
| === Price/ | === Price/ | ||
| 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 ==== | ||
| Line 145: | Line 153: | ||
| ^ Bugtracker ^ Speed ^ clicks/ | ^ Bugtracker ^ Speed ^ clicks/ | ||
| | Launchpad | | Launchpad | ||
| - | | Trac | 8 | 2 | 3 | - | no | no | yes (plugin) | + | | Trac | 8 | 2 | 3 | - | no | yes (plugin) |
| - | | Roundup | + | |
| + | ===== Conclusion ===== | ||
| + | The choice really just narrows down to wheter we'd like to host the tools ourselfs. | ||
| + | Hosting our own trac-instance | ||
| + | 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, | ||
| + | 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.1215087538.txt.gz · Last modified: by klette
