On Tue, Aug 09, 2016 at 01:20:05AM +0200, Michael Haggerty wrote:
> > but I
> > do not think it is sane to expect that the same quality and quantity
> > of reviews as we do here can be maintained with that thing.
> Could you elaborate why you would expect quality and/or quantity of
> reviews to suffer? I'm really curious, and I'd be happy to pass your
> feedback along to my colleagues.
Having done a lot of review here on the mailing list, as well as in
GitHub PRs, I vastly prefer the mailing list.
Here's a random list of things that I think I would miss:
- I really like the flow of having the commit message and diff dumped
in my editor. I'm very efficient at slicing and dicing text, omitting
uninteresting quoted bits, etc.
Web text boxes feel like a straitjacket. I do have a browser plugin
that opens them in vim. That helps, but it breaks the flow (I make a
comment, save the file, click "comment", then read to the next place,
click "+", then start a new vim instance for that comment). Besides
the tedium of clicking around, it loses the "unit" size of a single
email, where I may make many comments, go back and revise earlier
comments after reading more of the patch, etc.
- I really like the flow of having conversations next to patches. I can
look at the index of the mailing list folder and see what people are
talking about, how big the threads are, etc, at a glance. Moving
between messages and threads involve single keystrokes.
Similarly, having local storage is _fast_. I think GitHub is fine for
a web app. But when I'm reading a high-volume mailing list, I really
want to flip around quickly. If there's even 500ms to get to the next
message or thread, it feels clunky and slow to me. Obviously I spend
more than 500ms _reading_ most messages (though for some I see the
first paragraph and immediately jump away). It's just the latency
when I've decided I'm done with one thing and want to move to the
- For that matter, GitHub doesn't really have a good tool for random
conversations. There are issues, which you can vaguely use like a
thread, but it doesn't quite feel the same.
I think part of it is that I can view the mailing list both as a
series of threads _and_ as a stream of messages. So sometimes I mark
a thread as "read", and then see the next day that there are a ton of
new messages on it. Maybe those are uninteresting (and it's a single
keystroke to mark the thread again), but maybe that's a hint that
there's interesting discussion going on.
The threading in GitHub comments and pull requests is also not great.
Each PR or issue is its own thread, but it's totally flat inside.
There are no sub-threads to organize discussion, and it's sometimes
hard to see what people are replying to.
- When I move between a discussion and patches on the list and my local
git checkout, it's important to do so with minimal fuss. Which means
I want to use _context_ in my workflow. If I'm reading a thread, I
want there to be a keystroke for "jump to this thread in my
checkout". That's (relatively) easy for me to script via mutt (grab
these patches, apply them). It's a bit harder in the browser (the
best I've got is to copy-paste the URL to a script that pulls out the
PR number, then fetches and checks it out).
- A sort-of feature: the mailing list is actually fairly decentralized,
because of the "reply-to-all" convention. I don't know if anybody
else noticed, but vger seemed to be down Friday evening and Saturday
morning (at least my messages to the list got 400 SMTP codes, and no
new messages were delivered to me). But I still had some
conversations going with people, because our messages were mailed
directly (and the list eventually caught up).
Now that probably doesn't matter for GitHub, which seems to have
fairly reasonable uptime. It would matter if we picked a centralized
tool that didn't.
There are probably more, but I've run out of ranting steam for now. :)
> Here are some factors that I think will *improve* reviews:
I was going to respond point-by-point to a few of these, but I think I
covered most of it above. In short, I agree with many of the benefits
you list. In most cases, I've already reaped those benefits for my own
workflow (e.g., my "git am" workflow is pretty efficient now). But not
everybody has done so, and it's a lot to ask of casual contributors.
> Given that I work for GitHub, I'm uncomfortable doing any more advocacy
> here. If people have concrete questions, I'd be happy to answer them, on
> the list or in private.
Hopefully I provided some counterpoint. ;)
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