allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Bondarenko <jetmi...@gmail.com>
Subject Re: how to move tickets from SourceForge to ASF Allura
Date Fri, 29 Aug 2014 07:05:35 GMT
Sending manual emails to the top users sounds good to me.


On Mon, Aug 25, 2014 at 11:38 PM, Dave Brondsema <dave@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 : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message