<div dir="ltr"><div>Hi Ben - this sounds good, a couple of questions:</div><div><br></div><div>- What about the performance issue we noticed last week?</div><div>- What will happen to Phabricator diffs that are still mid-review? It would be a shame to have to move them to gitlab and interrupt the review trail. Can't we just shut Phabricator to new diffs but keep the possibility of working on existing ones?</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 17 Dec 2018 at 05:29, Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TL;DR. Given somewhat slower-than-expected progress on the Trac import I<br>
       suggest that we implement a pared-down migration on Tuesday.<br>
       See "The Plan" below.<br>
<br>
<br>
Hello everyone,<br>
<br>
Over the last few weeks we have been hard at work preparing the<br>
migration to GitLab. Currently the following things are ready:<br>
<br>
 * Hosting of GHC's repositories and those of its mirrors have been<br>
   prepared.<br>
<br>
 * Continuous integration has been configured for GHC.<br>
<br>
   All-in-all the GitLab migration has been quite timely since we were<br>
   recently notified by CircleCI of billing changes which will soon make<br>
   it quite difficult for us to continue using their services (see the<br>
   thread on ghc-devops for details).<br>
<br>
   Thankfully, moving CI to GitLab has been mostly painless and has<br>
   even enabled us to introduce testing of platforms which were<br>
   previously inaccessible to us under CircleCI.<br>
<br>
 * The various linters which previously ran via `arc lint` and gitolite<br>
   post-receive hooks have been ported to CI jobs.<br>
<br>
 * The Trac ticket migration is looking good although there are still a<br>
   significant number of details which need to be sorted out.<br>
<br>
 * The Wiki migration is in a similar state.<br>
<br>
Over the past weeks we have been in constant contact with GitLab's FOSS<br>
outreach group, who have been quite helpful in getting the eyes of<br>
GitLab employees on the issues affecting our transition. Thanks to<br>
especially to David Planella for his help so far.<br>
<br>
Unfortunately, there is one issue in particular [1] which is currently<br>
blocking the Trac migration. From my discussions with GitLab's upstream<br>
it sounds like it may be possible for them to prioritize a fix in the<br>
short-term. However, our aggressive migration timeline is a fair bit<br>
faster than GitLab's development cycle and consequently this certainly<br>
won't happen before our planned migration on Tuesday.<br>
<br>
<br>
# The Plan<br>
<br>
Given what remains to be done in the Trac migration I believe it would<br>
be a mistake to move ahead with the full migration as planned. However,<br>
in the interest of re-gaining functional continuous integration of<br>
patches as soon as possible I propose that we move ahead with moving<br>
code review on Tuesday.<br>
<br>
The plan would be as follows:<br>
<br>
 1. We setup the final <a href="http://gitlab.haskell.org" rel="noreferrer" target="_blank">gitlab.haskell.org</a> instance tomorrow; since the<br>
    Trac migration will not be run will need to create new accounts on<br>
    instance.<br>
<br>
 2. We begin officially accepting merge requests on this fresh GitLab<br>
    instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will<br>
    become GHC's official upstream repository.<br>
<br>
 3. We allow a week of transition time where new Differentials will<br>
    continue to be accepted via Phabricator.<br>
<br>
 4. After this transition period we place Phabricator in read-only mode.<br>
<br>
 5. When we are confident in the Trac migration (likely after the new<br>
    year) we move ahead with importing tickets and the wiki<br>
<br>
Previously I was skeptical of any plan that involved running the Trac<br>
migration against a live GitLab instance. However, further reflection<br>
I believe such a migration is safe and feasible. Moreover, given the<br>
constraints set upon us by the impending CircleCI changes, I think this<br>
is our best option to ensure continuity of CI.<br>
<br>
Thoughts?<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
[1] <a href="https://gitlab.com/gitlab-org/gitlab-ce/issues/46980" rel="noreferrer" target="_blank">https://gitlab.com/gitlab-org/gitlab-ce/issues/46980</a><br>
_______________________________________________<br>
Ghc-devops-group mailing list<br>
<a href="mailto:Ghc-devops-group@haskell.org" target="_blank">Ghc-devops-group@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group</a><br>
</blockquote></div>