[GHC DevOps Group] The future of Phabricator

[Herbert Valerio Riedel]

On 2018-10-30 at 00:54:42 -0400, Ben Gamari 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.

TL;DR. IMO, Phabricator is still the best tool we know about for *GHC's needs* ;-)

[...]

> For one, at this point we have no options for support in the event that
> something goes wrong as the company responsible for Phabricator,
> has closed their support channels to non-paying customers.

While it's certainly a good idea to have an emergency plan ready, I
don't think we need to act prematurely before something has actually
happened. Phabricator is open-source and therefore there's little that
can go so catastrophically wrong that we wouldn't give us more than enough
time to act upon.

(Also, there's still the option of becoming part of that
paying-customers group and thus influence their focus -- after all, we'd
be contributing to a improving an OSS codebase; and not a proprietary
closed product such as GitHub)

> 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.


While I do agree that Phabricator's impedance mismatch with Git idioms
has bugged me ever since we started using it (I even started
implementing https://github.com/haskell-infra/arc-lite as a proof of
concept but ran out of time), I still consider some of its features
unparalleled in PR-based workflows as provided by GitHub or GitLab.

For example, to me the support for stacked diffs outweights any
subjective inconvenience brought forward against Phabricator

https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/?fbclid=IwAR3JyQP5uCn6ENiHOTWd41y5D-U0_CCJ55_23nzKeUYTjgLASHu2dq5QCc0

The PR workflow is perfectly well-suited for trivial documentation
patches to a project; but that's for contributions that frankly are of
minor importance; they're surely nice to have, but they're not the kind
of contributions that are essential to GHC's long-term sustainability
IMO.

The reality IMO is that everybody tends to come up with this or that
complaint about a tool which isn't their favorite one, but it's hardly a
real barrier to contribution. In fact, I bet the majority of the people
that now complain about phabricator not being GitHub will be vocally
unhappy about having to create a GitLab account and that GitLab is not
GitHub...

Sure, by not trying to make everyone (specifically non-MVP contributors)
happy we might loose some typo fixes or whatever, but do we really want
to optimize the workflows for casual drive-by contributors which may
contribute a couple of trivial patches and then never be seen again, at
the expense of making life harder for what is already a complex enough
task: managing and reviewing complex patches to GHC where it's paramount
to use the best possible code-review facilities, and not shift the cost
from contributors to the even more important people, the ones maintaing
the projects as well as having intimate knowledge about the internals of
GHCs (but unfortunately have a very tight time & cognitive time budget
to spend on GHC, and which are the ones we really want to be able to
review those patches with as little cognitive overhead as possible.

So yes, phabricator is optimized for reviewers, and that's IMO a very
good thing and outweights the benefit of trying to bend over backwards
to make as many contributors as possible happy, of which there are
orders of magnitudes more than there GHC maintainers&experts.

An interest talk in this context is

"Rebuilding the Cathedral" by Nadia Eghbal
https://www.youtube.com/watch?v=VS6IpvTWwkQ

Which makes the very point that the most important people for a
project's sustainability are its maintainers rather than their
contributors.