[GHC DevOps Group] The future of Phabricator

Tue Oct 30 09:45:40 UTC 2018

What's to prevent GitLab from doing what Phabricator has once enough companies have committed to it?

⁣David Feuer
Well-Typed Consultant

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