Fwd: Re: About Trac to GitLab migration

Sajith Sasidharan sajith at hcoop.net
Thu Jul 23 16:10:13 UTC 2020


Hi,

I have things to report about Trac replacement!

Ben Gamari, who did the majority of work in moving haskell.org's Trac etc to
GitLab, has kindly answered my email.  Ben added Daniel Stone to the thread,
who managed freedesktop.org's migration to GitLab.

I will update this list with the rest of this conversation.

Regards,
Sajith.


-------- Forwarded Message --------
From: Ben Gamari
To: Sajith Sasidharan
Cc: Daniel Stone
Subject: Re: About Trac to GitLab migration
Date: Wed, 22 Jul 2020 19:26:29 -0400

Sajith Sasidharan <sajith at hcoop.net> writes:

> Hi Ben,
> 
Hi Sajith,

> I contribute to Tahoe-LAFS project (https://tahoe-lafs.org/).  We are
> looking
> at the possibility of moving our wiki and tickets from Trac to GitLab.  The
> consensus is that we should not self-host, so we'll likely move to
> gitlab.com.
> 
> It seems that haskell.org has done a Trac-to-GitLab migration successfully,
> and if I remember correctly from what was going in the mailing lists at the
> time, you did quite a bit of this work.
> 
> If my memory is incorrect, apologies!  Otherwise, have you (or anyone else)
> written about this experience somewhere?  What tools helped (TracBoat and
> the
> such), what worked, what did not work, what you would have done differently,
> and the such?
> 
Indeed I was principally responsible for the transition. You will find
an overview of the project here [1]. You may also be interested in our
tracking ticket on GitLab.com [2]. I assume you already know about
GitLab's FOSS program [3]? If not, do get in touch with them. They were
remarkably helpful. I've also CC'd Daniel Stone, who carried out
freedesktop.org's GitLab migration and who shared useful feedback when
we were planning the Haskell migration.

We set the bar quite high for the fidelity of the conversion and found
that TracBoat's output didn't quite meet that standard. In particular,
we had a few constraints:

 * Issue numbers must remain unchanged
 * Trac markup be faithfully converted to Markdown or reported as bad so
   it can be manualy fixed. This includes links to, e.g., comments
 * The Trac keyword field must be mapped to labels
 * A variety of other custom Trac fields must be preserved such that
   they could be reconstructed from only the data in the GitLab instance
   later
 * The Trac Wiki must be migrated faithfully, including intra- and
   inter-wiki links

To achieve this we opted to implement our own [3] migration tool. This
was, of course, a non-trivial investment but we are quite happy with the
result. However, this tool did require a bit of patching of our
self-hosted GitLab instance during the migration process since GitLab's
API wasn't quite up to the task.

Now since the migration is over we are happily using GitLab for issue
tracking, code review, and CI. On the whole it works quite well.
However, I would indeed advise you not to self-host if possible.
Administration, patching, and spam management is a non-trivial amount of
work for a small project. Moreover, GitLab requires a surprisingly large
amount of hardware to provide reasonable responsiveness.

There are also a number of limitations of GitLab that you should likely
keep in mind:

 * Quality of search is quite poor, even when Elasticsearch integration
   is in use. Of course, Trac's full-text search mechanism isn't
   great, but Trac makes up for this with a robust structured search
   story.

   In GitLab you have neither good full-text search, nor particularly
   strong structured data.

 * I've found gitlab.com, particularly its search function, to be at
   best slow and at worst unavailable. Admittedly, I'm not looked in a
   while so perhaps things have improved, but last I checked things were
   bad enough to deter us from moving our self-hosted instance to
   gitlab.com.

 * The Wiki is quite weak. We previously relied heavily on Trac's wiki
   for developer documentation and the like but have been forced to
   reevaluate this as GitLab's implementation becomes quite slow with large
   wikis.

Regardless, we are generally quite happy with the result of our
migration. While GitLab has its weaknesses, it's on the whole a great
product. The CI story it has enabled for us is particuarly strong.

Anyways, I hope this helps! I would be happy to chat if you have any
specific questions.

Cheers,

- Ben


[1] https://www.haskell.org/ghc/blog/20190403-infra-status.html
[2] https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55039 
[3] https://gitlab.haskell.org/bgamari/trac-to-remarkup




More information about the tahoe-dev mailing list