[GHC DevOps Group] The future of Phabricator

[Michal Terepeta]

Hope you don't mind if I add an opinion of a small/occasional
contributor to the thread.

Personally, I would prefer a move to GitHub. Mostly due to familiarity
and network effect (pretty much everyone is on GitHub).

But I would also consider a move to GitLab a big improvement over the
current Phab-based setup.  A git-based workflow would be great - I use
arc/Phab too rarely to really invest in learning them better. (I just
figured out the simplest way to use them that seems to work and I'm
sticking to it :) I haven't actually used GitLab before, but it seems
super easy to sign in using GitHub credentials and the interface seems
quite familiar.

One thing that was already mentioned is the ticket handling and I just
wanted to say "+1". I *really* dislike Trac - it's slow, unintuitive and
every time I use it I need to spend a couple of minutes to find the
guide to its own weird version of markdown... So a better place for
tickets that's tightly integrated with code code hosting/review tools
would be really cool! Which brings an interesting aspect of this
discussion - if I had to choose between "GitHub for code hosting/review
& Trac for tickets" vs "GitLab for everything", I'd prefer the latter.

- Michal


On Tue, Oct 30, 2018 at 10:51 PM Boespflug, Mathieu <m at tweag.io> wrote:

> Hi Ben,
>
> On Tue, 30 Oct 2018 at 18:47, Ben Gamari <ben at well-typed.com> wrote:
> >
> > ...
> >
> > It occurs to me that I never did sit down to write up my thoughts on
> > reviewable. I tried doing a few reviews with it [1] and indeed it is
> > quite good; in many ways it is comparable to Differential. [...]
> > However, it really feels like a band-aid, introducing another layer of
> > indirection and a distinct conversation venue all to make up for what
> > are plain deficiencies in GitHub's core product.
>
> Sure. That sounds fine to me though, or indeed no different than say,
> using GitHub XOR Gitlab for code hosting, Phabricator for review (and
> only for that), and Trac for tickets (not ideal but no worse than
> status quo). If Phabricator (the paid for hosted version) or
> Reviewable.io really are the superior review tools, and if as review
> tools they integrate seamlessy with GitHub (or Gitlab), then that's an
> option worth considering.
>
> The important things are: reducing the maintenance burden (by
> preferring hosted solutions) while still meeting developer
> requirements and supporting a workflow that is familiar to most.
>
> > > So keeping the review UX issues aside for a moment, are there other
> > > GitHub limitations that you anticipate would warrant automation bots à
> > > la Rust-lang?
> > >
> > Ultimately Rust's tools all exist for a reason. Bors works around
> > GitHub's lacking ability to merge-on-CI-pass, Highfive addresses the
> > lack of a flexible code owner notification system, among other things.
> > Both of these are features that we either have already or would like to
> > have.
>
> ... and I assume based on your positive assessment, are both
> out-of-the-box features of Gitlab that meet the requirements?
>
> > On the whole, I simply see very few advantages to using GitHub over
> > GitLab; the latter simply seems to me to be a generally superior product.
>
> That may well be the case. The main argument for GitHub is taking
> advantage of its network effect. But a big part of that is not having
> to manage a new set of credentials elsewhere, as well as remembering
> different user names for the same collaborators on different
> platforms. You're saying I can use my GitHub credentials to
> authenticate on Gitlab. So in the end we possibly wouldn't be losing
> much of that network effect.
>
> > > I'm not too worried about the CI story. The hard part with CircleCI
> > > isn't CircleCI, it's getting to a green CircleCI. But once we're
> > > there, moving to a green OtherCI shouldn't be much work.
> > >
> > Right, and we are largely already there!
>
> That's great to hear.
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181101/36909a7f/attachment.html>