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 next. - 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. ;) -Peff -- 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