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 > <>< >
