Consider using gerrit for code reviews

I'm gonna vote 👎 on this, but let's see what happens when we get people fully staffed.

Putting more tooling in the way of outside contributions is :( , particularly when Github's PR system is commonly accepted in the open source world.

I find gitHub code review tool to be much inferior compared to gerrit. The lack of 2 pane diff mode, the embedded comments (which can disappear without a trace based on some code change), the lack of marking what was already viewed, horrible history navigation and most of all the immediate comment notification makes it a very hard to work with tool.

I am not sold about gerrit, only had a recent experience with it and realized how much better it is compared to gitHub's code review. If there are other better code review tools that work well with gitHub
I am all for it.

I think gcloud-golang is also using gerrit, no? Does it negatively effect their outside contribution?

I believe gerrithub will create a gerrit CL when someone creates a pull
request.

On Thu, Aug 20, 2015 at 4:30 PM, JJ Geewax notifications@github.com wrote:

I'm gonna vote [image: 👎] on this, but let's see what happens when we
get people fully staffed.

Putting more tooling in the way of outside contributions is :( ,
particularly when Github's PR system is commonly accepted in the open
source world.

—
Reply to this email directly or view it on GitHub
#136 (comment)
.

I think gcloud-golang is also using gerrit, no? Does it negatively effect
their outside contribution?

Yes, we use Gerrit. Gerrit is used for all Go projects, so it works well
with the core contributors' workflow.

Hard to say whether Gerrit negatively influences outside contributions. We
do get occasional CLs from outside contributors.

@broady

I find gitHub code review tool to be much inferior compared to gerrit. The lack of 2 pane diff mode, the embedded comments (which can disappear without a trace based on some code change), the lack of marking what was already viewed, horrible history navigation and most of all the immediate comment notification makes it a very hard to work with tool.

Totally agree with the complaints -- but this project is about meeting our users where they are and using the tools they use.

I am not sold about gerrit, only had a recent experience with it and realized how much better it is compared to gitHub's code review. If there are other better code review tools that work well with gitHub
I am all for it.

I personally love gerrit... I used it with a previous company after we found ReviewBoard to be kind of annoying, but my 👎 vote sadly still stands...

I think gcloud-golang is also using gerrit, no? Does it negatively effect their outside contribution?

They do, however I don't think we have enough data to say yes or no. If I had to place a bet on this.... I'd say the typical contributor would be annoyed with needing to do anything extra to contribute...

@broady: If someone creates a PR inside Github (aka, doesn't do anything with gerrit), what happens?

@ryanseys

/cc @GoogleCloudPlatform/gcloud @ryanseys @blowmage @stephenplusplus @dhermes

@broady

@broady Do you mean we use gerrit for all Google-owned Go projects? Or that it's the standard for all open-source Go projects?

@mziccard

/cc @mziccard - Any thoughts on this?

@jboynes

/cc @jboynes - Opinon ?

What happens in gcloud-golang? Nothing. The PR just sits there. It doesn't
trigger anything automatically.

If gerrithub was linked, I think it creates a Gerrit CL.

Gerrit is the standard for open-source Go projects, like the Go project
itself, and the sub-repositories (i.e. everything under github.com/golang).

@broady

What happens in gcloud-golang? Nothing. The PR just sits there. It doesn't
trigger anything automatically.

So you guys can't do a code review inside just Github ? To contribute you really need to go the gerrit route, correct?

Gerrit is the standard for open-source Go projects, like the Go project
itself, and the sub-repositories (i.e. everything under github.com/golang).

Gotcha -- thanks @broady . That makes sense.

I don't believe there's really a standard in the Java world, so I think we have to actually have to give this some serious thought, where, lacking compelling reasons, the default here is stick with Github's tooling given our audience.

It's not that we "can't", it's that we won't. It's an awful experience. We tell people to use Gerrit instead.

@dsymonds

Cool - thanks @dsymonds

I agree that gerrit is a much happier experience :( but I'd still vote for the GH tooling simply due to momentum.

I don't personally care what gcloud-java does. If GitHub pull requests are the standard for the relevant community, and the heaviest users prefer it, I'd say go for it.

Here's another one: https://reviewable.io/ -- but I haven't used either.

I think the GH interface for reviews is sub-optimal, but I'm not sure having to incorporate another tool is worth it. I would rather let our communities start the trend and have us follow. And if that's the case for a certain language, that's fine. I don't think all of gcloud-* have to be consistent in process. Do what works for your team.

As far as the Node world, I haven't personally been a part of a project that preferred code reviews to be done off-site. If I was just stopping by to make a one-off contribution, I wouldn't be thrilled to have to learn something new. If we're just concerned with reviewing each others code, again, do whatever the team prefers.