[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab
#30857: migrate (some projects? everything?) from trac to gitlab
-------------------------------------------------+-------------------------
Reporter: anarcat | Owner: (none)
Type: project | Status: new
Priority: Medium | Milestone:
Component: Internal Services/Services Admin | Version:
Team |
Severity: Normal | Resolution:
Keywords: tickets-migration | Actual Points:
Parent ID: #29400 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by gaba):
Replying to [comment:41 anarcat]:
> > 1. ticket number preservation
>
> Agreed. I think it would be essential to keep that. Any self-respecting
migration tool should allow us to "dump" all the trac tickets into a
(single!) GitLab project, keeping ticket numbers.
Tickets will be imported by team/project. It will not work for us to have
ALL trac tickets in one project in gitlab.
And that brings me the question on where are we going to have sysadmin
tickets in gitlab? I was thinking as its own group in gitlab but you may
have other idea for it.
>
> > They want to not have collition between trac ticket numbers and gitlab
issue numbers.
>
> This, however, seems to say something else: does it mean that we
'''don't''' want Trac ticket #1 to be the same ticket as GitLab ticket #1?
That would be in contradiction with "ticket number preservation" in my
mind.
Sorry that I was not clear. Any new ticket in gitlab will have a number
that has not being assigned in trac yet. We preserve the number for
tickets that already exist.
>
> > That would mean to have new numbers for new tickets when starting to
use gitlab officially.
>
> I interpret this as meaning that, assuming we migrate Trac tickets from
1 to N when Trac is made readonly (for the migration, it can be turned off
after), the next ticket in gitlab will be N+1?
Yes.
>
> > 2) add all tickets (including closed ones)
> >
> > They want to have ALL tickets from trac in gitlab to preserve the
history of Tor in one place.
>
> Sure, that should be done. Then we have this "legacy" gitlab project
with a humongous pile of tickets like we have in Trac right now, but we
can "split" those up as needed by moving tickets around with the API.
>
> > 3) get all info from each ticket into an issue (including comments in
the trac ticket addded as a 'trac user' to the gitlab issue)
> >
> > This would mean to have each comment from each trac ticket as a
comment in the gitlab issue. The possible solution would be to have a
'trac user' in gitlab that is the one making all the comments that are
being migrated from trac.
>
> That makes sense as well, I'd be happy to see that happen, and I think
this is all the kind of stuff Tracboat should do.
>
> I would still put Trac readonly during and after the migration, then do
one last archival to the Internet archive. I would then create a
"redirection site" that would do things like:
>
> {{{
> https://trac.torproject.org/projects/tor/ticket/N ->
https://dip.tracproject.org/tor/legacy/issues/N
> https://trac.torproject.org/projects/tor/wiki/PAGE ->
https://dip.tracproject.org/tor/legacy/wiki/PAGE
> (...anything else?)
> }}}
>
> And *then* trac can be totally decommissioned (although I would keep
backups for a while, just to be sure, of course, but that's part of our
decommissioning procedure anyways.
Yes.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30857#comment:42>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs