You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2013/09/06 17:39:40 UTC
how to move tickets from SourceForge to ASF Allura
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
<><
Re: how to move tickets from SourceForge to ASF Allura
Posted by Dave Brondsema <da...@brondsema.net>.
Yeah, the overhead might be too much for this, although I do think it's a good
idea. SourceForge doesn't have an OpenID provider currently, and the OpenID
support in Allura is broken. Even after fixing it, it'd need additional work to
work nicely (e.g. Google uses a different extension, which has some security
risks to account for)
On 9/9/13 12:02 PM, Daniel Hinojosa wrote:
> 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.galoppini@gmail.com> wrote:
>
>> 2013/9/9 Dave Brondsema <da...@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?
>>
>>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: how to move tickets from SourceForge to ASF Allura
Posted by Daniel Hinojosa <dh...@slashdotmedia.com>.
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.galoppini@gmail.com> wrote:
> 2013/9/9 Dave Brondsema <da...@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
> > <><
> >
>
--
*Daniel Hinojosa*
*Community Manager, SourceForge / Slashdot Media*
p: 415.890.3608
e: d@slashdotmedia.com
facebook: facebook.com/d.Slashdotmedia
skype: hinojosad
Re: how to move tickets from SourceForge to ASF Allura
Posted by Roberto Galoppini <ro...@gmail.com>.
2013/9/9 Dave Brondsema <da...@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
> <><
>
Re: how to move tickets from SourceForge to ASF Allura
Posted by Daniel Hinojosa <dh...@slashdotmedia.com>.
Hi Dave,
I like your proposed mitigation for the ticket subscription. Same on votes.
d.
On Mon, Sep 9, 2013 at 8:19 AM, Dave Brondsema <da...@brondsema.net> wrote:
> 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.
>
> 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.
>
> 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
> <><
>
--
*Daniel Hinojosa*
*Community Manager, SourceForge / Slashdot Media*
p: 415.890.3608
e: d@slashdotmedia.com
facebook: facebook.com/d.Slashdotmedia
skype: hinojosad
Re: how to move tickets from SourceForge to ASF Allura
Posted by Dave Brondsema <da...@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.
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.
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
<><
Re: how to move tickets from SourceForge to ASF Allura
Posted by Wayne Witzel III <ww...@gmail.com>.
I like option 3 as well. Keeping the original numbers if possible. Since we
also reference tickets in a lot of commit messages.
On Fri, Sep 6, 2013 at 12:08 PM, Daniel Hinojosa <
dhinojosa@slashdotmedia.com> wrote:
> Dave,
>
> I agree with you that having as much history as possible would be the
> preferred model. With that, +1 on option 3.
>
> d.
>
>
> On Fri, Sep 6, 2013 at 8:39 AM, Dave Brondsema <da...@brondsema.net> 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
> > <><
> >
>
>
>
> --
> *Daniel Hinojosa*
> *Community Manager, SourceForge / Slashdot Media*
> p: 415.890.3608
> e: d@slashdotmedia.com
> facebook: facebook.com/d.Slashdotmedia
> skype: hinojosad
>
Re: how to move tickets from SourceForge to ASF Allura
Posted by Daniel Hinojosa <dh...@slashdotmedia.com>.
Dave,
I agree with you that having as much history as possible would be the
preferred model. With that, +1 on option 3.
d.
On Fri, Sep 6, 2013 at 8:39 AM, Dave Brondsema <da...@brondsema.net> 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
> <><
>
--
*Daniel Hinojosa*
*Community Manager, SourceForge / Slashdot Media*
p: 415.890.3608
e: d@slashdotmedia.com
facebook: facebook.com/d.Slashdotmedia
skype: hinojosad
Re: how to move tickets from SourceForge to ASF Allura
Posted by Dave Brondsema <da...@brondsema.net>.
On 9/9/13 2:13 PM, Rich Bowen wrote:
> On 09/06/2013 11:39 AM, Dave Brondsema wrote:
>> 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?
> From a product feature perspective, having a simple way to export your tickets
> from a project and import them into another Allura instance seems really
> important, so, thinking of this not as a one-time migration but as an actual
> feature ... is this possible from the Data Export feature (
> http://sourceforge.net/blog/project-data-export/) ?
>
>
Yes, that's the goal. The export is there, and we need to implement the import
portion: https://sourceforge.net/p/allura/tickets/6638/ For our particular
use-case we'll need some further work to filter which tickets we'll import
(delete some from the export file, or pull the API for all the tickets we want
and concat them)
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: how to move tickets from SourceForge to ASF Allura
Posted by Rich Bowen <rb...@rcbowen.com>.
On 09/06/2013 11:39 AM, Dave Brondsema wrote:
> 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?
From a product feature perspective, having a simple way to export your
tickets from a project and import them into another Allura instance
seems really important, so, thinking of this not as a one-time migration
but as an actual feature ... is this possible from the Data Export
feature ( http://sourceforge.net/blog/project-data-export/) ?
--
Rich Bowen
rbowen@rcbowen.com
Shosholoza
Re: how to move tickets from SourceForge to ASF Allura
Posted by Roberto Galoppini <ro...@gmail.com>.
2013/9/6 Dave Brondsema <da...@brondsema.net>
> 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.
>
As far as we redirect all existing tickets to the new home, explaining
clearly why they're redirected and what is changed (e.g. username issue) I
think that could be acceptable from an (old) end-user point of view.
Roberto
>
> How does that sound? Any other suggestions?
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>
Re: how to move tickets from SourceForge to ASF Allura
Posted by Dave Brondsema <da...@brondsema.net>.
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 <je...@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 <da...@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
>>> <><
>>>
>>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: how to move tickets from SourceForge to ASF Allura
Posted by Cory Johns <jo...@gmail.com>.
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 <je...@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 <da...@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
> > <><
> >
>
Re: how to move tickets from SourceForge to ASF Allura
Posted by Igor Bondarenko <je...@gmail.com>.
Sending manual emails to the top users sounds good to me.
On Mon, Aug 25, 2014 at 11:38 PM, Dave Brondsema <da...@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
> <><
>
Re: how to move tickets from SourceForge to ASF Allura
Posted by Dave Brondsema <da...@brondsema.net>.
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
<><
Re: how to move tickets from SourceForge to ASF Allura
Posted by Dave Brondsema <da...@brondsema.net>.
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
<><
Re: how to move tickets from SourceForge to ASF Allura
Posted by Dave Brondsema <da...@brondsema.net>.
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
<><