I think the "arc" barrier is significant. Personally, while I feel quite comfortable hacking on Haskell code, system tools are always a bit of a mystery. Those of you who help manage the infrastructure may feel like the tools are easy enough to pick up, but I'm sure there are many competent Haskell programmers out there who dread learning new tooling. (Perhaps I'm a representative sample of this set. I still say `git help merge` before just about every merge, just to make sure that I'm remembering the concepts correctly.)
I absolutely believe that we should use the best tools available and that committed GHC contributors should have to learn these tools as necessary. Though I've had my problems with Phab and `arc`, I'm confident that this tool was chosen after a deliberative process and am grateful that we have leaders in this area in our midst. All that said, I think that the suggestion just to accept GitHub pull requests will lead to confusion, if only for the namespace problem. If we start to accept pull requests, then we are de facto going to have to deal with both the GH issue tracker and Trac's (and Phab's), and that is a terrible place to be. Part of the automated response to pull request submissions could be a post on the GH pull request record pointing folks to the Phab review that was created in response. The pull request would then be closed. I agree with the comment that users will be more committed to learn Phab once they have contributed. That's why I wanted to point them to Phab in the automated response to the GH pull request. I think there's a psychological commitment made by a person once they click "submit pull request" and they will be happy enough to follow up on Phab, especially if commenting and such doesn't require the installation of a local tool. Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
