[GHC DevOps Group] Phabricator -> GitHub?

Manuel M T Chakravarty manuel.chakravarty at tweag.io
Tue Oct 10 07:10:06 UTC 2017


[RESENT MESSAGE — see https://mail.haskell.org/pipermail/ghc-devops-group/2017-October/000004.html]

[Includes all of Simon’s message.]

> Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>>:
> 
> Personally I prefer to stay with Phabricator because it's better for code reviews, and because we already use it.  Having said that, if a majority of the developer community would prefer GitHub, and there is effort available to make the transition, then we should do it. But I do have strong feelings on a couple of things:
> 
> - We should consult the whole developer community. Changing the code review tool affects not just potential contributors, but also the people doing the reviewing. If the reviewers are less productive or less keen to spend time on reviews, then overall quality will drop. An increase in contributions can only be supported if we also have an increase in the pool of people reviewing and merging contributions. It’s about increasing the size of the developer community, not drive-by contributions.

We will absolutely talk to more developers, but please keep in mind that projects like the Rust and Swift compiler use GitHub. These are projects that are striving and get lots of contributions. Rust had 120 active PRs last week and Swift had 132 active PRs. I don’t quite see what is so different about GHC.

> - We should use *one* code-review tool only.  Making a transition to a situation where we have two different code review tools (GitHub + reviewable.io <http://reviewable.io/>) would be a step backwards. (after all, one of the arguments below is against learning a new random tool….)
> 
> The alternative that we discussed in the past is to better support contributions via GitHub, which we could still do.

I am not at all arguing for reviewable.io <http://reviewable.io/> (I have never used the latter), but I don’t understand your argument. Firstly, why is GitHub + reviewable.io <http://reviewable.io/> worse than GitHub + Phabricator as mix? Secondly, the suggestion was only to use reviewable.io <http://reviewable.io/> for particularly heavy PRs. Thirdly, it still is much better than Phabricator on the new random tool front because it requires no custom infrastructure and the PRs still go through GitHub as usual.

In any case, I don’t want to argue for reviewable.io <http://reviewable.io/>. Let’s just say that, if we move to GitHub, and we decide at some point, we want extra code review power for select contributions, there are options.

Cheers,
Manuel

> On 9 October 2017 at 07:44, Manuel M T Chakravarty <manuel.chakravarty at tweag.io <mailto:manuel.chakravarty at tweag.io>> wrote:
> I have spoken to a number of people about the question of using GitHub pull requests and code reviews instead of Phabricator for GHC development. And while some people are quite happy with Phabricator and/or prefer it due to using it at work anyway, the majority of people I talked to would prefer to use GitHub. In fact, some people (such as Neil Mitchell, Will Jones (VP Engineering @ Habito), and myself) stated that they do not contribute patches to GHC because they don’t want to deal with the overhead that Phabricator imposes. (So far, I haven’t had anybody who said they would not contribute if they have to use GitHub, but obviously my sample set is small and likely skewed.)
> 
> Having said that, obviously, we will always find people preferring one tool over another. And also obviously, both tools can do the job (and for GitHub there are options for more sophisticated than the basic type of code reviews if need be: http://reviewable.io/ <http://reviewable.io/>).
> 
> Hence, I like to offer two technical and one social reasons why we should replace Phabricator by GitHub (and I do mean replace, not run both side-by-side).
> 
> = Technical
> 
> (1) Rule One of DevOps: minimise custom infrastructure
> [Our resources are scarce. Why waste them on something that can be outsourced (for free)?]
> 
> (2) We really need to sort out CI and integration with GitHub is easier — see also (1).
> 
> = Social
> 
> * Virtually every developer knows how to use GitHub and custom-anything creates friction. That learning Phabricator is little effort compared to learning to contribute to GHC is a red herring IMHO. Firstly, if the learning curve is steep, you don’t make it steeper. Secondly, there are people (e.g., Neil and me) who can very well contribute to GHC, but who don’t, because they don’t want waste time on yet another random tool. Life is too short!
> 
> The reason why I don’t want to run Phabricator and GitHub side-by-side is because this would fail to help with the two technical reasons.
> 
> Cheers,
> Manuel
> 
> PS: This is *not* about moving Trac to GitHub. We are only talking about pull requests and code reviews.
> 
> 
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org <mailto:Ghc-devops-group at haskell.org>
> https://haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group <https://haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group>
> 

_______________________________________________
Ghc-devops-group mailing list
Ghc-devops-group at haskell.org
https://haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://haskell.org/pipermail/ghc-devops-group/attachments/20171010/01d38a06/attachment.html>


More information about the Ghc-devops-group mailing list