<html><head></head><body><div dir="auto">What's to prevent GitLab from doing what Phabricator has once enough companies have committed to it?<br><br></div>
<div dir="auto"><!-- tmjah_g_1299s -->David Feuer<!-- tmjah_g_1299e --><br></div>
<div dir="auto"><!-- tmjah_g_1299s -->Well-Typed Consultant<!-- tmjah_g_1299e --></div>
<div class="gmail_quote" >On Oct 30, 2018, at 12:55 AM, Ben Gamari <<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="blue"><br>TL;DR. For several reasons I think we should consider alternatives to<br> Phabricator. My view is that GitLab seems like the best option.<br><br><br>Hello everyone,<br><br>Over the past year I have been growing increasingly weary of our<br>continued dependence on Phabricator. Without a doubt, its code review<br>interface is the best I have used. However, for a myriad of reasons I<br>am recently questioning whether it is still the best tool for GHC's<br>needs.<br><br><br># The problem<br><br>There are a number of reasons why I am currently uncertain about<br>Phabricator.<br><br>For one, at this point we have no options for support in the event that<br>something goes wrong as the company responsible for Phabricator,<br>Phacility, has closed their support channels to non-paying customers.<br>Furthermore, in the past year or two Phacility has been placing their<br>development resources in the parts their customers pay them for, which<br>appear to be much different that the parts that we actively use. For<br>this reason, some parts that we rely on seem oddly half-finished.<br><br>This concern was recently underscored by some rather unfortunate<br>misfeatures in Harbormaster which resulted in broken CI after the<br>Hadrian merge and now apparent bugs which have made it difficult to<br>migrate to the CircleCI integration we previously prepared.<br><br>Perhaps most importantly, in our recent development priorities survey<br>our use of Phabricator was the most common complaint by a fair margin,<br>both in case of respondents who have contributed patches and those who<br>have not. On the whole, past contributors and potential future<br>contributors alike have strongly indicated that they want a more<br>Git-like experience. Of course, this wasn't terribly surprising; this<br>is just the most recent case where contributors have made this<br>preference known.<br><br>Frankly, in a sense it is hard to blame them. The fact that users need<br>to install a PHP tool, Arcanist, to contribute anything but<br>documentation patches has always seemed like unnecessary friction to me<br>and I would be quite happy to be rid of it. Indeed we have had a quite<br>healthy number of GitHub documentation patches since we started<br>accepting them. This makes me thing that there may indeed be potential<br>contributoes that we are leaving on the table.<br><br><br># What to do<br><br>With Rackspace support ending at the end of year, now may be a good<br>time to consider whether we really want to continue on this road.<br>Phabricator is great at code review but I am less and less certain that<br>it is worth the maintenance uncertainty and potential lost contributors<br>that it costs.<br><br>Moreover, good alternatives seem closer at-hand than they were when we<br>deployed Phabricator.<br><br><br>## Move to GitHub<br><br>When people complain about our infrastructure, they often use GitHub as<br>the example of what they would like to see. However, realistically I<br>have a hard time seeing GitHub as a viable option. Its feature set is simply<br>insufficient enough to handle the needs of a larger project like GHC<br>without significant external tooling (as seen in the case of Rust-lang).<br><br>The concrete reasons have been well-documented in previous discussions<br>but, to summarize,<br><br> * its review functionality is extremely painful to use with larger<br> patches<br><br> * rebased patches lead to extreme confusion and lost review comments<br><br> * it lacks support for pre-receive hooks, which serve as a last line of<br> defense to prevent unintended submodule changes<br><br> * its inability to deal with external tickets is problematic<br><br> * there is essentially no possibility that we could eventually migrate<br> GHC's tickets to GitHub's ticket tracker without considerable data<br> loss (much less manage the ticket load that would result), meaning<br> that we would forever be stuck with maintaining Trac.<br><br> * on a personal note, its search functionality has often left me<br> empty-handed<br><br>On the whole, these issues seem pretty hard to surmount.<br><br><br>## Move to GitLab<br><br>In using GitLab for another project over the past months I have been<br>positively surprised by its quality. It handles rebased merge requests<br>far better than GitHub, has functional search, and quite a usable review<br>interface. Furthermore, upstream has been extremely responsive to<br>suggestions for improvement [1]. Even out-of-the-box it seems to be<br>flexible enough to accommodate our needs, supporting integration with<br>external issue trackers, having reasonable release management features,<br>and support for code owners to automate review triaging (replacing much<br>of the functionality of Phabricator's Herald).<br><br>Finally, other FOSS projects' [3] recent migrations from Phabrictor to<br>GitLab have shown that GitLab-the-company is quite willing to offer help<br>when needed. I took some time this weekend to try setting up a quick GHC<br>instance [2] to play around with. Even after just a few hours of playing<br>around I think the result is surprisingly usable.<br><br>Out of curiosity I also played around with importing some tickets from<br>Trac (building on Matt Pickering's Trac-to-Maniphest migration tool).<br>With relatively little effort I was even able to get nearly all of our<br>tickets (as of 9 months ago) imported while preserving ticket numbers<br>(although there are naturally a few wrinkles that would need to be<br>worked out). Naturally, I think we should treat the question of ticket<br>tracker migration as an orthogonal one to code review, but it is good to<br>know that this is possible.<br><br><br>## Continue with Phabricator<br><br>Continuing with Phabricator is of course an option. Its review<br>functionality is great and it has served us reasonably well. However,<br>compared to GitLab and even GitHub of today its features seem less<br>distinguished than they once did. Moreover, the prospect of having to<br>maintain a largely stagnant product with no support strikes me as a<br>slightly dangerous game to play. Working around the issues we have<br>recently encountered has already cost a non-negligible amount of time.<br><br><br># The bottom line<br><br>If it wasn't clear already, I think that we should strongly consider a<br>move to GitLab. At this point it seems clear that it isn't going to<br>vanish, has a steady pace of development, is featureful, and available.<br><br>However, these are just my thoughts. What do you think?<br><br>Cheers,<br><br>- Ben<br><br><br>[1] 11.4 will ship with a file tree view in the code review interface,<br> which I reported<br> (<a href="https://gitlab.com/gitlab-org/gitlab-ce/issues/46474">https://gitlab.com/gitlab-org/gitlab-ce/issues/46474</a>) as being is<br> one of the Phabricator features I missed the most during review<br><br>[2] <a href="https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641">https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641</a><br><br>[3] The GNOME and <a href="http://freedesktop.org">freedesktop.org</a> projects have recently migrated, the<br> former from a hodge-podge of self-hosted services and the latter<br> from Phabricator<br> <br></pre><pre class="blue"><hr><br>ghc-devs mailing list<br>ghc-devs@haskell.org<br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br></pre></blockquote></div></body></html>