SourceForge Ticket Migration

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

SourceForge Ticket Migration

aaalafayette
Administrator
Currently source forge is being used for tickets (bugs, patch tracking, feature requests) for example: http://sourceforge.net/p/triplea/feature-requests/

Git doesn't eliminate the need for patch tracking, but it does lesson it. So we need to determine if we want to keep using source forge for tickets, or if we want to migrate to another ticketing engine. Likely as well that ticket migration could be involved.

First let's consider what a desirable future would look like, then we can figure out how we want to head in that direction.

So for tickets, we have options:

- We can keep using sourceforge
- JIRA provides open source licenses
- BugZilla and other bug tracking software: bugzero, RT (https://www.bestpractical.com/rt/)
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

aaalafayette
Administrator
I think right now we should consider alternatives, and see if Atlassian will even give us an open source license for JIRA. If so, it would be interesting to know if they'll allow Bamboo or other tools to be used by the same license.
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

redrum
Administrator
I don't want to keep sourceforge for tickets. I think considering if we can use github or something like JIRA would be best.
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

aaalafayette
Administrator
It looks like github has an issue tracker: https://github.com/blog/411-github-issue-tracker

I think it's probably between JIRA and github for ticketing systems. Both are cloud based (good for us, nothing to set up, no servers to keep up, no monthly cost). Though, we still need to set up a website so we can apply for an Atlassian open source license to use JIRA for free (and see which other products Atlassian will let us use)
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

redrum
Administrator
The problem with github issues is I don't think you can add attachments which we need. So would need to find a creative way around that if we go with github.
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

bernat
github issues all the way :) just host the files on some file hosting server (mega, etc) and link it.
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

aaalafayette
Administrator
github issues looks to be a winner (at least for developers). I'm not sure about having average-tripleA user going to github to submit feature requests.

This leaves a question of how do we receive bug reports and feature requests? Would one answer be via forum? Recommendations?
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

bernat
I see no issue in using the Github for this too. I've seen countless projects using it like that. We can also accept via forum and create a ticket from that transforming it to a dev work :)
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

Veqryn
Administrator
we do not need to migrate the sourceforge feature requests

bug tickets, and attachments for them, is a bigger concern, and it would be nice if people could submit these without registering
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

redrum
Administrator
Looks like we can use something like this: https://github.com/cmungall/gosf2github

We'll probably have to do any attachments manually though.
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

aaalafayette
Administrator
I'm in favor of doing a "white-list" type of migration rather than a full export-import. Namely, there are not so many tickets that we can't migrate them by hand. We could perhaps migration like this:
- review source forge ticket
 -- close it if the ticket is old or has been already fixed
 -- close if the ticket makes no sense
 -- close if the ticket has no specifics to work on (ie: "I loaded the game once and got an error message")
- if the ticket looks good, create a github ticket
 -- add the github ticket link to the sourceforge ticket, close the sourceforge ticket

We'll then be left with either source forge tickets we do not with to migrate, or no sourceforge tickets.
Reply | Threaded
Open this post in threaded view
|

Re: SourceForge Ticket Migration

redrum
Administrator
@aaalafayette - So I have similar thoughts though I would like to review all tickets on SF and close all of them we don't want to migrate. Then use some automated tool to move the remaining ones over. Then review them in github and add any necessary comments, etc.

I've already taken a pass a week or 2 ago on all the tickets and closed a good number of them that were either already fixed or just completed useless. We probably need Veqryn to some extend to help go through a lot of them since many of them are rather old.