I think that is reasonable for at least the top users, most of whom are present or past Allura devs/contributors. For the rest I don't think it'd be appropriate for SourceForge to transfer email addresses over to an Apache instance. The export & import functionality also doesn't cover subscription info and I'm not too eager to write more code / mongo scripts just to handle that :)
I haven't had a chance to move this forward yet but hopefully next week I will, and I'll set up accounts for top users and try a full ticket import. If it goes well, we'll redirect the SourceForge urls and notify the top users. -Dave On 9/4/14 9:11 AM, Cory Johns wrote: > Would it be untoward to "reserve" existing usernames for users that have > participated in the Allura project (recently?) by creating the accounts > with the username and email but with a randomly generated password? That > way, a user could "claim" their account using the password reset mechanism, > and we could automatically resubscribe them. > > But that does raise issues of transferring email addresses from SourceForge > to the Apache Allura project, so maybe that's a non-starter, even though it > would be in the interest of preserving functionality that they have > explicitly opted in to. > > > On Fri, Aug 29, 2014 at 3:05 AM, Igor Bondarenko <jetmi...@gmail.com> wrote: > >> Sending manual emails to the top users sounds good to me. >> >> >> On Mon, Aug 25, 2014 at 11:38 PM, Dave Brondsema <d...@brondsema.net> >> wrote: >> >>> Igor has fixed the first two TODO items mentioned below, so we are >>> theoretically >>> ready to move tickets. I want to discuss how we handle user's >> connections >>> to >>> these tickets though. >>> >>> First, usernames aren't going to match up, so the import will put >>> "originally >>> submitted by ..." etc in the text of tickets and comments. I think we >>> should >>> make accounts on forge-allura.apache.org for the most-frequently used >>> usernames >>> so that those are preserved at least. >>> >>> Second, there are users who have subscribed to tickets to get updates on >>> them. >>> Those will get lost. There are 9 users that are subscribed to 10+ >>> tickets, and >>> 399 users are subscribed to less than 10 (mostly 1 or 2) tickets. Some >> of >>> which >>> might be private tickets that aren't going to move from SourceForge to >>> Apache. >>> We could find a way to extract exactly what tickets & users are affected >>> and do >>> a one-off custom email to notify each of them that the tickets have been >>> moved >>> to a new URL and if they want to continue to get notifications, they'll >>> have to >>> create an account on forge-allura.apache.org and re-subscribe. That >>> sounds like >>> a lot of work and may actually cause more confusion than benefit to all >>> those >>> people. I am thinking its best use of our time to manually email only >> the >>> top >>> users, and not everyone else. >>> >>> Thoughts? >>> >>> >>> On 7/22/14 12:38 PM, Dave Brondsema wrote: >>>> 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 >>> <>< >>> >> > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
