[tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#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