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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs