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