Update: Alex has been working on a script in #7510 which I have been reviewing and just merged. We are now able to take a full ticket export and filter only tickets we want to move, convert milestones to match Allura releases (derived from git commits & tags) instead of SourceForge development sprints, move 'size' custom field to a label (used by SF folks for internal estimating), and some other changes.
You can see the script at: https://forge-allura.apache.org/p/allura/git/ci/master/tree/scripts/prepare-allura-tickets-for-import.py and browse a partial test import at https://sf-dbrondsema-1015.sb.sf.net/p/testit/tickets-import4/ TODO: * fix attachment import https://sourceforge.net/p/allura/tickets/7580/ * set up a way to do redirects from SourceForge urls * create accounts on forge-allura.a.o for most frequent users, so username association is cleaner On 6/26/14 12:23 PM, Dave Brondsema wrote: > I'm starting to make a little progress on this again. We had general > agreement > about using option 3. I have recently gone through tons of tickets making > non-Allura (e.g. SourceForge internal) tickets all be private. > > Since we have a ticket import & export feature now, next step would be to > export > tickets, write a small script to filter the export for just public tickets, > and > then do a local test import and see how everything comes through. I'm sure > there will be some things to work through then (e.g. username mapping for the > most common users at least). > > On 9/6/13 11:39 AM, Dave Brondsema wrote: >> We should move our tickets from https://sourceforge.net/p/allura/tickets/ to >> https://forge-allura.apache.org/p/allura/ There's a lot of tickets there, >> and >> the hardest part I think is that its a mix of Allura tickets and non-OSS >> SourceForge tickets too. (Lately we've been making non-Allura tickets >> private, >> and also using different milestones, but that's not 100% true for all the >> tickets on SF). >> >> I want to propose a few options for how we want to handle the Allura tickets >> and >> then after that, SourceForge can figure out how to adapt some of its other >> needs >> for internal tickets, related tickets, scheduling, etc. >> >> 1) Clean start; don't move any tickets. Easy, but a lot of context and >> history >> will be left on SF. Also there are many open tickets that would have to be >> re-created. >> >> 2) Move open Allura tickets, preserving ticket #s (or, possibly, giving them >> new >> numbers starting at 1). This would leave behind closed tickets that aren't >> "current" any more. We would have to sort out what open tickets are "allura" >> tickets and which are not. >> >> 3) Move all Allura tickets. We would have all of the project history in one >> place. But it would take even more time to sort through all the tickets to >> determine what is "allura" and should be moved, and what should not. >> >> I prefer option 3. It's more work but will be very helpful to have all >> tickets >> in one place. I have pretty good knowledge of all the tickets and can be the >> one to sort out which to move and which to keep on SF. >> >> As far as the technical work to do a move, we can export all the data using >> the >> APIs. And we can write an import utility which handles the Allura api/export >> format (which would be good to do anyway). Many usernames wouldn't match up, >> and would have to be changed to "anonymous" or create a stub user in Allura >> (my >> preference). Cross-references (to wiki pages, chat logs, SF site-support >> tickets, etc) would break. >> >> How does that sound? Any other suggestions? >> >> > > > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
