Hi Dave, I like your proposed mitigation for the ticket subscription. Same on votes.
d. On Mon, Sep 9, 2013 at 8:19 AM, Dave Brondsema <d...@brondsema.net> wrote: > Subscriptions & votes won't migrate, really. Anyone subscribed to updates > on a > SourceForge Allura ticket won't be subscribed to the Apache Allura ticket. > Idea: send a one-time email from SourceForge saying that the ticket is now > moved > and you can create an account on the new site and re-subscribe. > > Votes: we can't migrate who specifically voted for a ticket. We should be > able > to migrate the total # of up & down votes, though. But first we need to > expose > the vote numbers in our API, so that they can be exported. > > 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 > <>< > -- *Daniel Hinojosa* *Community Manager, SourceForge / Slashdot Media* p: 415.890.3608 e: d...@slashdotmedia.com facebook: facebook.com/d.Slashdotmedia skype: hinojosad
