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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 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.

 > 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.

 > 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?

 > 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30857#comment:41>
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