On Sun, 27 Apr 2014, Sam Halliday <sam.halliday at gmail.com> wrote: > Sorry, I replied to jani and not the list...
...and I in turn replied to the private message. Oops. Let's try again. On Sun, 27 Apr 2014, Sam Halliday <sam.halliday at gmail.com> wrote: > In my experience the github pull review process is by far superior to > any other solution. I read and write code in Emacs. I read and write email in Emacs. I read and write basically anything I can in Emacs. I have near total control of that environment, mainly limited by my abilities. Any review process that forces me to review code (in other words, read code and write text) in an environment that I don't have control over will be inferior to me. The same is true for people using some other editor or mail client; they can choose and control that environment, but they have no control over github. > If I were contributing to you, it requires having to learn your > process, create diffs and then attach them, and then after a review it > means tracking down the bits of the code you're referring to and > manually reconciling that with my repo and sending you more > diffs. Using github, it's like all open source developers agree on a > basic set of common processes. Funny you should say that; it used to be that emailed patches and mailing list based review were the common process! I am not sure which one is more popular these days (or what would be the appropriate metric for comparing). To be honest, I am slightly concerned by the popularity of github. Despite being a hosting site primarily for open source, it *is* a proprietary platform. Source code hosting is plain git, but AFAIK all the rest (review process, issue tracking, and so on) is pretty much at the whim and mercy of the company running it. They make a change, you adapt. If you don't want to adapt, it's not easy to switch over to another service provider either if you've built your process around github. So even if the features of github amazed me (they don't), I would have pretty strong reservations about relying on them. Disclaimer, I don't make the calls for this project, I only speak for myself. BR, Jani.
