[GHC DevOps Group] The future of Phabricator

Tue Oct 30 09:16:59 UTC 2018

Gitlab has built-in CI support. This means it's well-integrated. I would
expect the CI to improve.

On Tue, Oct 30, 2018, 10:08 Simon Marlow <marlowsd at gmail.com> wrote:

> I'm entirely happy to move, provided (1) whatever we move to provides the
> functionality we need, and (2) it's clearly what the community wants
> (considering both current and future contributors). In the past when moving
> to GitHub was brought up, there were a handful of core contributors who
> argued strongly in favour of Phabricator, do we think that's changed? Do we
> have any indication of whether the survey respondents who were
> anti-Phabricator would be pro- or anti-GitLab?
>
> Personally I'd like to optimise for more code review, because I think that
> more than anything else will increase quality and community ownership of
> the project. If using new tooling will make code review a more central part
> of our workflow, then that would be a good thing. Right now I think we're
> very Trac-centric, and the integration between Trac and Phabricator isn't
> great; if we could move to a solution with tighter integration between
> tickets/code-review/wiki, that would be an improvement in my view. But not
> GitHub, for the reasons you gave.
>
> Would GitLab solve the CI issues? I don't think you mentioned that
> explicitly.
>
> Cheers
> Simon
>
> On Tue, 30 Oct 2018 at 04:54, 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-devops-group mailing list
>> Ghc-devops-group at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>>
> _______________________________________________
> 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-devs/attachments/20181030/c580aa42/attachment.html>