[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:                                       |  Actual Points:
Parent ID:  #29400                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by anarcat):

 >  The wiki of trac can be easily redirect without a gigantic redirect
 file because it can be set in the section and page directly.
 >
 > Tickets are a different story.
 >
 > Gitlab is also organized in projects and we have been using Trac with
 tags. We might not have a complete mapping between the two that doesn't
 overlap two projects and we might have to make some hard choices.

 I think it's a similar problem, actually: every ticket, every wiki page is
 in this single project in Trac. I doubt that it makes sense to keep the
 same "one gigantic wiki" approach if/when we migrate to GitLab: each
 project or team could have its own wiki...

 So we will *probably* want to split wikis *and* tickets up by "component"
 or some sort of delimiter. This could be done in the migration or after,
 in GitLab.

 > Furthermore when we did the last survey about trac vs github a few years
 ago we talked that trac links had been used as references for papers so
 preserving those was a hard requirement.

 Yes, that was my understanding as well. One thing I am thinking of is to
 make sure that, in the migration, the original URL of the migrated page
 (ticket or wiki) is retained somewhere in GitLab so that it can be
 searched. That way we could have a redirection that finds that stuff more
 easily. I don't know how practical that can be, but that's the kind of
 stuff we'll find out about when we start working on the migration.

 > I am personally for making trac read only and above all not searchable.
 That way we save a lot of resources and we still preserve old tickets.

 Well, maybe I'm not familiar enough with Trac, but what does that
 *actually* mean? We might be able to disable all users and disable user
 registration, but then people can still search for tickets and crawl the
 website and cause trouble. If we disable all queries, then people can't
 find tickets any more, and I'm not even sure we can just disable searching
 like that.

 In any case, this all means maintaining Trac forever: "readonly" still
 means "Trac is installed, running, upgraded and maintained", and I would
 very much like to stop doing that eventually.

 > Finally, I think we should start to migrate active tickets of certain
 projects only at this point, so that we don't go through a radical switch
 from one system to another, also while we just freeze old tickets.

 So my enquiries so far at the migration systems is they (well, "it",
 really) proceed in one big batch, per Trac project. Because we have a
 single Trac project, it will actually be pretty difficult to migrate
 tickets one at a time: I suspect that will not be possible at all, and
 especially tricky if we want to retain ticket number associations.

 To put it quite bluntly, we're need to shit or get off the pot here at
 some point. :) Maybe a few teams can start using it for new projects: the
 website stuff is a good example. Or small projects can be migrated if they
 don't mind losing ticket references.

 But if ticket portability is that critical, I think the only way this can
 be ensured in the long term is to do a proper migration, with Trac ticket
 metadata embedded inside GitLab tickets.

 Because there's no way we can keep maintaining Trac forever and I am not
 sure at all we'll be able to permanently archive it. That's still an open
 question, mind you, but I can't help but feel that if we're going to
 migrate tickets anyways, we might as well do it correctly...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30857#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online