GitLab migration status

Ben Gamari ben at well-typed.com
Mon Dec 17 05:29:00 UTC 2018


TL;DR. Given somewhat slower-than-expected progress on the Trac import I
       suggest that we implement a pared-down migration on Tuesday.
       See "The Plan" below.


Hello everyone,

Over the last few weeks we have been hard at work preparing the
migration to GitLab. Currently the following things are ready:

 * Hosting of GHC's repositories and those of its mirrors have been
   prepared.

 * Continuous integration has been configured for GHC.

   All-in-all the GitLab migration has been quite timely since we were
   recently notified by CircleCI of billing changes which will soon make
   it quite difficult for us to continue using their services (see the
   thread on ghc-devops for details).

   Thankfully, moving CI to GitLab has been mostly painless and has
   even enabled us to introduce testing of platforms which were
   previously inaccessible to us under CircleCI.

 * The various linters which previously ran via `arc lint` and gitolite
   post-receive hooks have been ported to CI jobs.

 * The Trac ticket migration is looking good although there are still a
   significant number of details which need to be sorted out.

 * The Wiki migration is in a similar state.

Over the past weeks we have been in constant contact with GitLab's FOSS
outreach group, who have been quite helpful in getting the eyes of
GitLab employees on the issues affecting our transition. Thanks to
especially to David Planella for his help so far.

Unfortunately, there is one issue in particular [1] which is currently
blocking the Trac migration. From my discussions with GitLab's upstream
it sounds like it may be possible for them to prioritize a fix in the
short-term. However, our aggressive migration timeline is a fair bit
faster than GitLab's development cycle and consequently this certainly
won't happen before our planned migration on Tuesday.


# The Plan

Given what remains to be done in the Trac migration I believe it would
be a mistake to move ahead with the full migration as planned. However,
in the interest of re-gaining functional continuous integration of
patches as soon as possible I propose that we move ahead with moving
code review on Tuesday.

The plan would be as follows:

 1. We setup the final gitlab.haskell.org instance tomorrow; since the
    Trac migration will not be run will need to create new accounts on
    instance.

 2. We begin officially accepting merge requests on this fresh GitLab
    instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will
    become GHC's official upstream repository.

 3. We allow a week of transition time where new Differentials will
    continue to be accepted via Phabricator.

 4. After this transition period we place Phabricator in read-only mode.

 5. When we are confident in the Trac migration (likely after the new
    year) we move ahead with importing tickets and the wiki

Previously I was skeptical of any plan that involved running the Trac
migration against a live GitLab instance. However, further reflection
I believe such a migration is safe and feasible. Moreover, given the
constraints set upon us by the impending CircleCI changes, I think this
is our best option to ensure continuity of CI.

Thoughts?

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/46980
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181217/0caa457b/attachment.sig>


More information about the ghc-devs mailing list