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 10:37] – fixed trac rpc stuff. Changed a lot in newer versions 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 ==== | ||
| - | + | 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/ | ^ 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.1215081461.txt.gz · Last modified: by klette
