<div><div dir="auto">Hey simon!</div></div><div dir="auto">I actually did some digging. And it looks like currently gitlab basically does a git diff of the two branches and does that computation on every page reload. </div><div dir="auto"><br></div><div dir="auto">1). There currently is no caching —- some of the folks on the Haskell infra team could help perhaps but they need to be given access to the setup for that to happen. </div><div dir="auto"><br></div><div dir="auto">2) the complexity of the git diff is linear in the commit history length between the two branches being compared </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Some of these things could be mitigated easily, but I spoke with one of the folks on the Haskell infra team and it sounds like ultimately either patching the gitlab gitaly server or providing a more efficient api compatible replacement are what would be needed. </div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 17, 2018 at 3:18 AM Simon Jakobi via ghc-devs <<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Ben,<div><br></div><div>in my experience Gitlab has been extremely slow at showing commit diffs to the point that it gives up and returns a 502: <a href="https://gitlab.staging.haskell.org/ghc/ghc/issues/15944" target="_blank">https://gitlab.staging.haskell.org/ghc/ghc/issues/15944</a></div><div><br></div><div>Is this possibly related to any resource constraints on our instance?</div><div><br></div><div>Cheers,</div><div>Simon</div></div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">Am Mo., 17. Dez. 2018 um 06:29 Uhr schrieb Ben Gamari <<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>