<URL: http://bugs.freeciv.org/Ticket/Display.html?id=16811 >
> [book - Mon Dec 29 08:39:03 2008]: > > Here is what needs to happen: > 1. A host for the bug tracker must be found. This is > either a machine someone can install/configure > bugzilla on, or a service hosting bugzilla. > 2. The current RT system needs to be frozen, all > new requests redirected to the new tracker, and > the public bug report address updated everywhere. > 3. Current outstanding tickets and history should be > moved to the new tracker. > > The problem has always been 1, since a dedicated > machine (e.g. in a data center) costs money, or a > free service is restricted (e.g. in allowed space) > or missing some key functionality. I have to ask yet again - though it isn't Bugzilla, has anyone seriously looked into sourceforge/tigris ? If not, has anyone considered going to any of the big hosting companies and see if they'd consider donating hosting? > Assuming a solution to the above exists, 2 is hard > because the only people (person?) with the required > access to the RT machine is not an active developer > and/or checks freeciv-dev only infrequently (besides > probably not having the time to make the changes in > RT, if that is even possible). I've done things like this in the past where all that was required was to replace all the CGI executables in such a way that they simply redirect the user to the new equivalent program. For example, when looking at this issue, the redirect CGI would display a message that the new location has moved for ten seconds and offer the user the ability to click to go there faster, or automatically go to .../show_bug.cgi?bug_id=RT16811 where Bugzilla would automatically translate from the bug alias to the proper bug ID in the new system. That is generally extremely easy to do. > 3 is not crucial; I assume there are less than 100 > important open tickets, which can be moved by hand > as they are handled, and the RT system could be kept > in "read-only" mode to make the history available > (in the minimum-effort scenario). Importing ticket history is relatively straightforward with Bugzilla. Doing that is as simple as adding comments to the appropriate table, and activity to the activity log. > If as you said using bugzilla would help encourage > developer contributions from the community then I am > strongly for it. This project is in great need of help > from competent coders to handle bug reports, assist > less experienced programmers with their ideas, and fix > the design mistakes that have broken past working > features (e.g. borders) and are causing new development > to stagnate. My experience is that open source projects benefit from transparency with users and developers. When it's easy for a wanna-be developer to look through issue lists, they can often pick something that'll be easy for them to "get their feet wet" in contributing. Bugzilla developers use this very method to mentor new developers - encouraging new developers to take on small changes to learn how the Bugzilla development process works and to get to know the new developers coding style. Developers mentor new developers through code reviews. Once code makes it through a review process, it goes through a similar approval process then gets published. I could go on, but I think you get the idea. It's appropriate to guard potential security issues from most others, but everything else is pretty much open game. KB _______________________________________________ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
