Hacker News new | ask | show | jobs
by erikb 4421 days ago
TL;DR Email filtering + git (the shell tool) + text editor solves all of these problems without using fancy tools, imho.

To me this looks like a typical attempt to solve a work process problem via technology. Using any code review tool doesn't help if you don't get code review done right. If you filter notifications based on rules in the tool or let the developers do it via email filtering is basically a question of philosophy. If you look at a Diff that way or another also doesn't change much about the review process in itself. Don't solve process questions with more software features!

IMHO getting loads of emails is great. I can filter by myself what is interesting to me right now. And worse than the one or two uninteresting emails every quarter is when I don't get the information I need. A non-engineer middle manager is allowed to complain about email overload in my eyes. A developer should be able to handle pure text.

And while we are at it, I also believe that less is more. No matter which repository hosts my code, I do code reviews on my computer with my own developer tools. I'm not even sure how the current version of GitHub or Bitbucket diffs looks like. These websites are basically the shell scripts and disk space that are used to backup my code and allow other people to access it. If a developer wants to do a code review he can also decide on his tools. The rest is just email and "git merge" (--no-ff). But that's just my opinion.

1 comments

I'm not sure if you're referring to the same situation or not. Can you really handle email from > 100 engineers on the same project? On top of all the non-code review emails you might have to deal with?

Also, you mention doing code review with your own tools on your own machine but I don't think that's the use case being discussed by the OP. It sounds like you're discussing reviewing the code to decide if you should pull it (since it's happening solely on your machine). The OP though is talking about a discussion of the code that happens between 2 or MORE people. Tools help that.

Being able to mark specific lines with comments or questions and have a back and forth between the submitters and reviewers doesn't seem like something easy to do if you're doing all the code review on your local machine.

Take a look at some chromium code reviews. Here's one with about 7 people participating

https://codereview.chromium.org/231133002/

And you can see inline comments, for example here's a few

https://codereview.chromium.org/231133002/diff/120001/cc/ani...

Is there a good way for that to happen offline on your local machine to involve 7 people?

I'm not an expert but I think that's how most Linux or related code is developed. Git + Bash + Vim/Emacs + Mailinglist/direct mail. They solve it by review hierarchy. One person has the responsibility to pull code or not and he in turn asks for a pull request from the maintainer one step higher when he has gathered enough new material. This doesn't just ensure fast development but also ensures that each commit is reviewed a few times before it gets into the main branch.

To answer the question about the >100 emails: Yes. From nearly everywhere I can I pull each and every email and then filter via filter rules and google's priority inbox (which you can mimic with open source tools as far as I've read). I seriously have only one or two emails more to handle than I want to in a span of three months. Sometimes I want an email with a specific topic, sometimes nearly everything a specific person writes or says, and it all gets piped and filtered quite well.

That's the awesomeness of pure text. There are not many limits to what you can achieve by having simple and well understood text formats. On the other hand the messaging in these programs is limited to what the program was meant to do. What a Phabricator filter rule is not able to do you are never able to do with Phabricator notifications. But emails where not meant to be sent and received in today's huge amounts, yet it's not a problem that can't be solved. Even if it is an open source tool that you install on your own server it's quite hard to make it do something different.