Hi Roberto, I'm all for the OID option, assuming the coding over-head is within reasonable bounds (a few hours of work?). In the end, it seems that OID is going the way of the Dinosaur, at least in some cases, since Facebook won that war (or is it a skirmish?)...
d. On Mon, Sep 9, 2013 at 8:52 AM, Roberto Galoppini < roberto.galopp...@gmail.com> wrote: > 2013/9/9 Dave Brondsema <d...@brondsema.net> > > > 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. > > > > It would be cool if we could allow SourceForge users to authenticate using > their own SourceForge credentials. Allura has some support for OpenID, > ideally this could be done by having a SourceForge OpenID server in place. > > Thoughts? > > > > > > > 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. > > > > The total should be enough, I think. > > Roberto > > > > > > 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
