<URL: http://bugs.freeciv.org/Ticket/Display.html?id=16811 >
Daniel Markstedt wrote:
> <URL: http://bugs.freeciv.org/Ticket/Display.html?id=16811 >
>>> sourceforge.net: The question was if bugzilla could run on SF.net webspace?
>> Would be nice.
As has already been mentioned - SF has its own issue tracking system.
> "Disk Quota: Each project is provided 100MB of disk space for their
> usage." I'm quite sure the RT database ecxeeds that already. (
Why is that? What is causing the the high disk space usage?
Attachments? Issues (unlikely)? Code? Something else?
>>> icculus.org: IIRC, this was Per's contact. Status?
>>> seul.org: IIRC, this was Egor's contact. Status?
>> Is that any better than freeciv.org?
>> What about GNA?
> If you mean the tracker, there was the problem that all projects use
> common bug numbering. If we were to import a database of tens of
> thousands of reports, it'd upset that system.
Bugzilla provides the ability to use an alias for a bug, so it wouldn't
be a problem to create "FCRT<issueid>" as an alias for those that want
to use the "old" issue numbers. That makes it easy to move to from
system and not worry about renumbering. JIRA uses numbering per-project
so the same is true there.
>> To me the biggest issue is carrying over the bug database. Not that
>> this is a show-stopper since it's clear that RT is not going to last
>> forever and the longer we wait the worst the problem there will get -
>> but, as RT is a simple database and bugzilla (or whatever) is a simple
>> database it really shouldn't be too hard to transfer the whole thing over.
Jason, I agree. The good thing about Bugzilla is that it does have the
ability to import XML. The question is, how to deal with the bug's
history. So - before migrating to any system, I think it's fair to ask
- what are the requirements for data coming from the old system? How
much of it must be carried over versus what parts can be left behind? I
would have to assume that the RT system would be available for at least
a short period after a migration was completed at least so that old data
could still be looked up.
Typically, the way I've done migrations like these is to write an import
script that imports data from an existing system into the new system,
first from a backed-up copy for development and testing purposes, then
on migration day, from the live system.
Freeciv-dev mailing list