On 2012.7.17 10:49 PM, Junio C Hamano wrote: > By allowing people to easily publish a completed work, and making it > easier for them to let others peek at their work, Git hosting > services like GitHub are wonderful. But I am not conviced that > quality code reviews like we do on the mailing list can be done with > existing Web based interface to a satisfactory degree. In this instance, I was just using Github for repository storage. I was hoping I could just submit a remote git repository and people would look at it from there. No Github required. I understand this makes things very convenient for you to review patches, let me convey my POV... After I'm exhausted from volunteering all the coding work, rather than submitting a URL to a remote repository I find I have to learn new specialized tools. It's extra learning and work, an extra step to screw up, and foreign to me (even as a experienced git user). It is of little benefit to me as a casual volunteer submitter. I can see if you've been on the git mailing list for a while and have git-am and all that set up, this system is great. But it comes at a cost which is offloaded onto new and casual contributors. > Patches with proposed commit log messages are sent via e-mail, > people can review them and comment on them with quotes from the > relevant part of the patch. The review can even be made offline, > yet at the end, the list archive is an easy one-stop location you > need to go to see how the changes progressed, what the background > thinking was, etc. for all the changes that matter. > > Look at recent ones (randomly, $gmane/199492, $gmane/199497, > $gmane/200750, $gmane/201477, $gmane/201434), and their re-rolls, > and admire how well the process works. > > I've played with GitHub's in-line code comment interface, but > honestly, it is cumbersome to use, for one thing, but more > importantly, you have to click around various repositories of pull > requestors, dig around to see in-line comments, and I do not see how > we can keep a coherent "discussion" like we do on the mailing list. > > There may be a hosting site with better code review features, but > all the code review of Git happens on this mailing list, and that is > not likely to change in the near future. Everything you've said above is correct... but it creates a procedure optimized for the convenience of the long time reviewers at the expense of new and casual submissions. I'm going to guess you live in email and have your client setup to do fancy things to extract patches from your mailbox and the like. This sort of specialized setup makes people bounce right off the submission process. At OSCON I was asking around for help getting things setup so I could submit patches here properly. As soon as they said "which mail daemon are you running?", I said "stop! I don't want to know any more". I have too many things to do to be fiddling with my mailer configuration just to submit volunteer work in the right form (that said, I'm pleased as punch that git-send-email now has instructions for sending via GMail). You're volunteers, too. We're all volunteers, so a more balanced submission process would be nice. But since you brought Github up... (I get the impression its kind of a dirty word around here) As somebody who doesn't live in email anymore (once upon a time I did), I find the Github Pull Request model to be an excellent... I'm not even going to use the word "compromise" because I don't feel like either side has been compromised... it's an excellent enhancement. The commits and conversations about the commits are all there on one page. Looking at a commit is a click away (I usually open them all in tabs at once, much faster). You can comment on them as a whole or inline. Those comments appear BOTH in the commit AND in the larger conversation on the pull request keeping it coherent, no clicking around. And it has email mirroring. All that and its tracked and organized in an issue tracker. Here's an example that includes commits, discussion about the larger issue, comments on commits, more commits based on those comments, and so on. As you can see, the conversation is complete and coherent. It wasn't always this way, but they're constantly improving. https://github.com/schwern/test-more/pull/319 A concrete downside it is that it does not work offline. I agree that's a problem. I don't think it's a veto. There are various work arounds which are less complicated than your typical git-to-email-to-git setup. We can talk about that you're interested. I've gone all in on Github Pull Requests such that most of my projects don't even have mailing lists (issues are used for discussion). This avoids a split community between Github and the mailing list. And they have email mirroring, so issue discussion can be done all in email (I prefer email for things that involve push notification and replies). Github has a nice API and it would be possible to create a Github Pull Request <-> Mailing List gateway. Perl 5 uses something like that for bug reports. All bug reports submitted via web or email all go into a bug tracker. All discussion on the web is mirrored to a thread on the mailing list and vice versa. Web users are happy. Mailing list users are happy. Everything is archived and organized in the tracker. If you were interested in going down this road, I'd be interested in helping. Step one would be to have pull requests on Github posted to the mailing list. Link to the pull request, links to each individual commit. Then those who want to work on Github can do it. Step two would be to have activity on the pull request mirrored back to the list, still a SMOP. Step three would be to have replies on the list mirrored back into the Github discussion. It could even submit the pull request with git-send-email and mirror individual replies to patches back as comments on individual Github commits. If all the clicking and opening tabs in a browser feels uncomfortable to you... its something you learn like anything else. Less and less people are comfortable in mail clients. Who is the system optimized for? It doesn't have to be a zero sum game. If you're interested, I'd be happy to help put something like this together if it will break the "ease of review" vs "ease of submission" deadlock. -- Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html