<div dir="ltr">I like Niklas's suggestion of a middle-ground approach. There are benefits to using phabricator (and arc), but there should be a lowered-bar approach where people can start contributing through github (even though they may be forced to do the code review on phabricator).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 1:42 PM, Niklas Hambüchen <span dir="ltr"><<a href="mailto:mail@nh2.me" target="_blank">mail@nh2.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I would recommend against moving code reviews to Github.<br>
I like it and use it all the time for my own projects, but for a large<br>
project like GHC, its code reviews are too basic (comments get lost in<br>
multi-round reviews), and its customisation an process enforcement is<br>
too weak; but that has all been mentioned already on the<br>
<a href="https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub</a> page you linked.<br>
<br>
I do however recommend accepting pull requests via Github.<br>
<br>
This is already the case for simple changes: In the past I asked Austin<br>
"can you pull this from my branch on Github called XXX", and it went in<br>
without problems and without me having to use arc locally.<br>
<br>
But this process could be more automated:<br>
<br>
For Ganeti (cluster manager made by Google, written largely in Haskell)<br>
I built a tool (<a href="https://github.com/google/pull-request-mailer" rel="noreferrer" target="_blank">https://github.com/google/pull-request-mailer</a>) that<br>
listens for pull requests and sends them to the mailing list (Ganeti's<br>
preferred way of accepting patches and doing reviews). We built it<br>
because some people (me included) liked the Github workflow (push<br>
branch, click button) more than `git format-patch`+`git send-email`. You<br>
can see an example at <a href="https://github.com/ganeti/ganeti/pull/22" rel="noreferrer" target="_blank">https://github.com/ganeti/ganeti/pull/22</a>.<br>
The tool then replies on Github that discussion of the change please be<br>
held on the mailing list. That has worked so far.<br>
It can also handle force-pushes when a PR gets updated based on<br>
feedback. Writing it and setting it up only took a few days.<br>
<br>
I think it wouldn't be too difficult to do the same for GHC: A small<br>
tool that imports Github PRs into Phabricator.<br>
<br>
I don't like the arc user experience. It's modeled in the same way as<br>
ReviewBoard, and just pushing a branch is easier in my opinion.<br>
<br>
However, Phabricator is quite good as a review tool. Its inability to<br>
review multiple commits is nasty, but I guess that'll be fixed at some<br>
point. If not, such an import tool I suggest could to the squashing for you.<br>
<br>
Unfortunately there is currently no open source review tool that can<br>
handle reviewing entire branches AND multiple revisions of such<br>
branches. It's possible to build them though, some companies have<br>
internal review tools that do it and they work extremely well.<br>
<br>
I believe that a simple automated import setup could address many of the<br>
points in <a href="https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator</a>.<br>
<br>
Niklas<br>
<span class=""><br>
On 01/09/15 20:34, Thomas Miedema wrote:<br>
> Hello all,<br>
><br>
> my arguments against Phabricator are here:<br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator</a>.<br>
><br>
> Some quotes from #ghc to pique your curiosity (there are some 50 more):<br>
> * "is arc broken today?"<br>
> * "arc is a frickin' mystery."<br>
> * "i have a theory that i've managed to create a revision that phab<br>
> can't handle."<br>
> * "Diffs just seem to be too expensive to create ... I can't blame<br>
> contributors for not wanting to do this for every atomic change"<br>
> * "but seriously, we can't require this for contributing to GHC... the<br>
> entry barrier is already high enough"<br>
><br>
> GitHub has side-by-side diffs<br>
</span>> <<a href="https://github.com/blog/1884-introducing-split-diffs" rel="noreferrer" target="_blank">https://github.com/blog/1884-introducing-split-diffs</a>> nowadays, and<br>
<span class="">> Travis-CI can run `./validate --fast` comfortably<br>
</span>> <<a href="https://travis-ci.org/ghc/ghc/builds" rel="noreferrer" target="_blank">https://travis-ci.org/ghc/ghc/builds</a>>.<br>
><br>
> *Proposal: accept pull requests from contributors on<br>
> <a href="https://github.com/ghc/ghc.*" rel="noreferrer" target="_blank">https://github.com/ghc/ghc.*</a><br>
<span class="">><br>
> Details:<br>
> * use Travis-CI to validate pull requests.<br>
> * keep using the Trac issue tracker (contributors are encouraged to put<br>
> a link to their pull-request in the 'Differential Revisions' field).<br>
> * keep using the Trac wiki.<br>
> * in discussions on GitHub, use <a href="https://ghc.haskell.org/ticket/1234" rel="noreferrer" target="_blank">https://ghc.haskell.org/ticket/1234</a> to<br>
> refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself.<br>
</span>> * keep pushing to <a href="http://git.haskell.org" rel="noreferrer" target="_blank">git.haskell.org</a> <<a href="http://git.haskell.org" rel="noreferrer" target="_blank">http://git.haskell.org</a>>, where the<br>
<span class="">> existing Git receive hooks can do their job keeping tabs, trailing<br>
> whitespace and dangling submodule references out, notify Trac and send<br>
> emails. Committers close pull-requests manually, just like they do Trac<br>
> tickets.<br>
> * keep running Phabricator for as long as necessary.<br>
> * mention that pull requests are accepted on<br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs</a>.<br>
><br>
> My expectation is that the majority of patches will start coming in via<br>
> pull requests, the number of contributions will go up, commits will be<br>
> smaller, and there will be more of them per pull request (contributors<br>
> will be able to put style changes and refactorings into separate<br>
> commits, without jumping through a bunch of hoops).<br>
><br>
> Reviewers will get many more emails. Other arguments against GitHub are<br>
> here: <a href="https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub</a>.<br>
><br>
> I probably missed a few things, so fire away.<br>
><br>
> Thanks,<br>
> Thomas<br>
><br>
><br>
><br>
</span>> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div>