<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Andres,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 06.06.2018 um 18:34 schrieb Andres Löh <<a href="mailto:andres@well-typed.com" class="">andres@well-typed.com</a>>:</div><div class=""><div class=""><br class=""></div></div></blockquote>[..]<br class=""><blockquote type="cite" class=""><div class=""><div class="">I haven't been following all the discussions in as much detail as I<br class="">perhaps should have, but is there currently anything that prevents us<br class="">from reaching our CI goals while continuing to use Phabricator? If not,<br class="">I suggest we continue trying that (which in my perception used to be<br class="">the plan; if not, please correct me).<br class=""></div></div></blockquote><div><br class=""></div><div>Yes, there is a serious obstacle to reaching our CI goals: with Phabricator we cannot currently run CI on differentials (aka pull requests), whereas with GitHub we get that functionality for free. This is why Ben wrote in his answer to my original message,</div><div><br class=""></div><div><blockquote type="cite" class=""><span style="font-family: Menlo-Regular; font-size: 15px;" class="">All of this certainly complicates the CI story. On one hand, I've been</span><br style="font-family: Menlo-Regular; font-size: 15px;" class=""><span style="font-family: Menlo-Regular; font-size: 15px;" class="">a tad reluctant to spend too much time hacking Phabricator/CircleCI</span><br style="font-family: Menlo-Regular; font-size: 15px;" class=""><span style="font-family: Menlo-Regular; font-size: 15px;" class="">integration together given the Phabricator situation. On the other hand,</span><br style="font-family: Menlo-Regular; font-size: 15px;" class=""><span style="font-family: Menlo-Regular; font-size: 15px;" class="">CircleCI and Appveyor both only support GitHub, so a move to, for</span><br style="font-family: Menlo-Regular; font-size: 15px;" class=""><font face="Menlo-Regular" class=""><span style="font-size: 15px;" class="">instance, GitLab doesn’t really unblock us.</span></font></blockquote><div><br class=""></div>We have been dancing around this issue for months now. (We can, of course, continue doing this for a few more months…)<br class=""><br class=""></div><div>Cheers,</div><div>Manuel</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Cheers,<br class=""> Andres<br class=""><br class="">On Wed, Jun 06, 2018 at 10:21:34AM +0200, Boespflug, Mathieu wrote:<br class=""><blockquote type="cite" class="">Hi Gershom,<br class=""><br class="">On 6 June 2018 at 03:23, Gershom B <<a href="mailto:gershomb@gmail.com" class="">gershomb@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Tue, Jun 5, 2018 at 4:51 PM, Simon Peyton Jones<br class=""><<a href="mailto:simonpj@microsoft.com" class="">simonpj@microsoft.com</a>> wrote:<br class=""><blockquote type="cite" class="">I have no inside knowledge, but I suspect that Microsoft's acquisition of Github means<br class="">- that GitHub will be largely undisturbed culturally<br class="">- that GitHub will have more oomph behind it, so it'll become yet<br class=""> more the de-facto choice than it already is<br class=""></blockquote><br class="">For what it's worth, the latter is definitely not happening. [...]<br class="">Some metrics have shown that there has been a<br class="">marked increase in imports of github accounts to gitlab in the past<br class="">day or so.<br class=""></blockquote><br class="">I assume you're referring to this:<br class=""><a href="https://twitter.com/gitlab/status/1004143715844124673" class="">https://twitter.com/gitlab/status/1004143715844124673</a>. I think it's<br class="">premature to draw any inference from a single metric, let alone<br class="">"definite" ones. Adoption is the result of the *net* inflow of users<br class="">(new users minus lost users) integrated over time. With any<br class="">substantial change, there are always going to be some disgruntled<br class="">users, and others hedging their bets. That says little about the<br class="">influx (or lack thereof) of new users and about the longer term trend.<br class=""><br class=""><blockquote type="cite" class="">Certainly the expectation is that microsoft will evolve github in<br class="">_some_ direction under its management, and this uncertainty enough is<br class="">sufficient to drive some migration -- and should give pause to GHC<br class="">plans as well -- it doesn't seem like a savvy move to cut over to<br class="">something that could well be a moving target until some dust settles.<br class=""></blockquote><br class="">I understand that some people out there are concerned about the GitHub<br class="">acquisition. But at this point in the maturity of the infrastructure,<br class="">there are more pressing concerns than what will Microsoft do.<br class=""><br class="">* As seen here, <a href="https://circleci.com/gh/ghc/ghc" class="">https://circleci.com/gh/ghc/ghc</a>, master is currently<br class="">red on everything but x86_64-linux (sans LLVM, sans Hadrian).<br class="">* This means that starting from a stock Debian Jessie, we can't get<br class="">validate to pass on stock virtualized infrastrure (except for one).<br class="">* So the first order of business is to get ghc HEAD to a sufficient<br class="">level of quality that validate passes everywhere and so that CI<br class="">becomes useful.<br class="">* None of this work is GitHub specific. Nor all that CircleCI or<br class="">Appveyor specific for that matter (work is currently focused on<br class="">improving the test suite).<br class="">* Our GitHub lock-in factor is currently low to pretty much absent,<br class="">and would remain low even if the review workflow becomes more<br class="">systematically GitHub centric (it already is for some small<br class="">contributions).<br class="">* That's because tickets remain on Trac, and the code along with the<br class="">entirety of its history remains in a standard Git repository, GitHub<br class="">or not. Also because GitHub is not a CI provider, those providers we<br class="">do use integrate with other code hosting solutions (e.g. Appveyor with<br class="">GitLab), and the surface area of CI provider-specific code is small.<br class=""><br class="">Now, this isn't to say that other options (e.g. GitLab or Bitbucket,<br class="">for code review and/or for code hosting and/or for CI) aren't worth<br class="">considering medium term. It's that I see no reason to stall first<br class="">getting to a stable situation where CI is green on all "Tier 1"<br class="">platforms on all types of hardware, nor to fear accepting even more<br class="">contributions from GitHub users.<br class=""><br class="">Best,<br class="">_______________________________________________<br class="">Ghc-devops-group mailing list<br class=""><a href="mailto:Ghc-devops-group@haskell.org" class="">Ghc-devops-group@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group<br class=""></blockquote><br class="">-- <br class="">Andres Löh, Haskell Consultant<br class="">Well-Typed LLP, <a href="http://www.well-typed.com" class="">http://www.well-typed.com</a><br class=""><br class="">Registered in England & Wales, OC335890<br class="">118 Wymering Mansions, Wymering Road, London W9 2NF, England<br class="">_______________________________________________<br class="">Ghc-devops-group mailing list<br class=""><a href="mailto:Ghc-devops-group@haskell.org" class="">Ghc-devops-group@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group<br class=""></div></div></blockquote></div><br class=""></body></html>