incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Galoppini <roberto.galopp...@gmail.com>
Subject Re: how to move tickets from SourceForge to ASF Allura
Date Mon, 09 Sep 2013 15:52:37 GMT
2013/9/9 Dave Brondsema <dave@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 : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>

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