Proposal: accept pull requests on GitHub

[Simon Marlow]

On 01/09/2015 11:34, Thomas Miedema wrote:
> Hello all,
>
> my arguments against Phabricator are here:
> https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.

Thanks for taking the time to summarize all the issues.

Personally, I think github's support for code reviews is too weak to 
recommend it over Phabricator.  The multiple-email problem is a killer 
all by itself.

We can improve the workflow for Phabricator to address some of the 
issues you raise are fixable, such as fixing the base revision to use, 
and ignoring untracked files (these are local settings, I believe).

Stacks of commits are hard to reviewers to follow, so making them easier 
might have a detrimental effect on our processes.  It might feel better 
for the author, but discovering what changed between two branches of 
multiple commits on github is almost impossible.  Instead the 
recommended workflow seems to be to add more commits, which makes the 
history harder to read later.

I have only had to update my arc once.  Is that a big problem?

Cheers
Simon


> Some quotes from #ghc to pique your curiosity (there are some 50 more):
>   * "is arc broken today?"
>   * "arc is a frickin' mystery."
>   * "i have a theory that i've managed to create a revision that phab
> can't handle."
>   * "Diffs just seem to be too expensive to create ... I can't blame
> contributors for not wanting to do this for every atomic change"
>   * "but seriously, we can't require this for contributing to GHC... the
> entry barrier is already high enough"
>
> GitHub has side-by-side diffs
> <https://github.com/blog/1884-introducing-split-diffs> nowadays, and
> Travis-CI can run `./validate --fast` comfortably
> <https://travis-ci.org/ghc/ghc/builds>.
>
> *Proposal: accept pull requests from contributors on
> https://github.com/ghc/ghc.*
>
> Details:
>   * use Travis-CI to validate pull requests.
>   * keep using the Trac issue tracker (contributors are encouraged to
> put a link to their pull-request in the 'Differential Revisions' field).
>   * keep using the Trac wiki.
>   * in discussions on GitHub, use https://ghc.haskell.org/ticket/1234 to
> refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself.
>   * keep pushing to git.haskell.org <http://git.haskell.org>, where the
> existing Git receive hooks can do their job keeping tabs, trailing
> whitespace and dangling submodule references out, notify Trac and send
> emails. Committers close pull-requests manually, just like they do Trac
> tickets.
>   * keep running Phabricator for as long as necessary.
>   * mention that pull requests are accepted on
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs.
>
> My expectation is that the majority of patches will start coming in via
> pull requests, the number of contributions will go up, commits will be
> smaller, and there will be more of them per pull request (contributors
> will be able to put style changes and refactorings into separate
> commits, without jumping through a bunch of hoops).
>
> Reviewers will get many more emails. Other arguments against GitHub are
> here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub.
>
> I probably missed a few things, so fire away.
>
> Thanks,
> Thomas
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>