Consider using gerrit for code reviews

[aozarov]

http://gerrithub.io/

[jgeewax]

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.

[aozarov]

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?

[broady]

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)
.

[broady]

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.

[jgeewax]

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?

[jgeewax]

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

[jgeewax]

@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?

[jgeewax]

/cc @mziccard - Any thoughts on this?

[jgeewax]

/cc @jboynes - Opinon ?

[broady]

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).

[jgeewax]

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.

[dsymonds]

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.

[jgeewax]

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.

[dsymonds]

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.

[stephenplusplus]

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.

[stephenplusplus]

@aozarov 2-pane diff mode: https://github.com/GoogleCloudPlatform/gcloud-node/pull/94/files?diff=split :)

[mziccard]

I don't have a strong opinion on the matter. We can all agree that Gerrit has a better experience wrt Github's PR. However, I have the feeling (no evidence whatsoever) that the users that are familiar with Github's PR are much more than the users familiar with Gerrit.

I just had a look at Gerrithub and I don't think that a PR in Github triggers a Gerrit CL (as I hoped) but please correct me if I am wrong.

[blowmage]

I've used Gerrit at other jobs and for contributing to OpenStack, and I'm a 👎 on requiring it for open source contributions. I haven't found the advantages to be worth the cost. But I'm also a filthy rubyist so you can safely disregard my opinion. :)

[quartzmo]

I strongly feel that requiring Gerrit for contributions would negatively impact Ruby community participation in the project.

[jgeewax]

For example -- we'd lose people making docstring changes. I know if I can fork -> click the edit button -> send pull request, I'm much more likely to submit a change.

If I'm required to hit the command line... no thanks.

[blowmage]

One more data point:

So I created PR for gcloud-golang for the CoC. A CL was not created in Gerrit for my PR. Then I was told, in the nicest way possible, that the contribution didn't count and they had to do it over. The CL was created manually, and there is no attribution given for the contribution.

So, if I was unfamiliar of the Gerrit requirement, the end result for my contribution is someone else gets to take credit for it and I get to feel dumb about it. This is why I do not believe this is not a good experience for bringing outside folks into open source projects.

[mziccard]

This PR has been open for a while. It seems from the discussion that we should stick to github's suboptimal code review in order to favor user contributions. If you feel we should give this more thoughts feel free to reopen.