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
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.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html