[GHC DevOps Group] Fwd: Phabricator -> GitHub?
Manuel M T Chakravarty
manuel.chakravarty at tweag.io
Tue Oct 10 07:29:50 UTC 2017
[RESENT MESSAGE — see https://mail.haskell.org/pipermail/ghc-devops-group/2017-October/000004.html]
> From: Simon Marlow <marlowsd at gmail.com>
> Subject: Aw: [GHC DevOps Group] Phabricator -> GitHub?
> Date: 9. Oktober 2017 um 23:08:58 GMT+11
> To: Manuel M T Chakravarty <manuel.chakravarty at tweag.io>
> Cc: ghc-devops-group at haskell.org
>
> On 9 October 2017 at 13:04, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
> On 9 October 2017 at 12:10, Manuel M T Chakravarty <manuel.chakravarty at tweag.io <mailto:manuel.chakravarty at tweag.io>> wrote:
>> 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.
>
> LLVM uses Phabricator and I didn't count how many PRs they have open, but it looks like a *lot*, and these are all active: https://reviews.llvm.org/differential/query/lks1dJdapQFa/#R <https://reviews.llvm.org/differential/query/lks1dJdapQFa/#R>
>
> So I don't buy the argument that we have to move to GitHub to get more contributions. Phabricator is clearly not a barrier for LLVM, so why should it be a barrier for 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?
>
> I'm saying GitHub + reviewable.io <http://reviewable.io/> would be worse than either GitHub alone, or Phabricator alone.
>
> Secondly, the suggestion was only to use reviewable.io <http://reviewable.io/> for particularly heavy PRs.
>
> I think that would be worse, because we have some PRs going through different code review tools. On Phabricator I have a single dashboard that shows me which PRs are needing my attention, I don't want to have to visit two different tools to see that.
>
> 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.
>
> I do buy the custom infrastructure argument in general - setting up our own CI has definitely taken a lot of Ben's time. I actually really liked having Travis for my GHC fork on GitHub. That was when it used to work, before our build exceeded what Travis would give us. So I guess that illustrates two things: custom infrastructure is nice when it works, but we're at the mercy of the suppliers.
>
> (sorry, I meant to say "outsourced infrastructure", not "custom infrastructure" above)
>
> Cheers
> Simon
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://haskell.org/pipermail/ghc-devops-group/attachments/20171010/9b0e4c62/attachment-0001.html>
More information about the Ghc-devops-group
mailing list