[bradfitz]

To summarize:

We now mirror GitHub PRs into Gerrit. Gerrit is still our upstream Git server. Gerrit is still where we do reviews and press the "Merge" button. (And once merged, it gets mirrored back to GitHub)

But now we have a bot that slurps PRs into Gerrit and syncs comments back and forth and closes PRs when needed. (We'll do more fine-grained comment sync in the future. We just shipped an "MVP" for the Go 1.11 tree opening).

Some more information is at https://golang.org/wiki/GerritBot

Code is at https://github.com/golang/build/blob/master/cmd/gerritbot/ge...

[eloff]

This is smart, decreasing the hurdles to contributions will inevitably result in more contributions. Economics 101. And I don't think it necessarily follows that they will be lower quality either, maybe for first time contributors, but we all start at the same place and have to learn. More first time contributors will also lead to more repeat contributors.

[Washuu]

Any time I come across a project that uses Gerrit I immediately abandon any proposed patches I had planned to submit. Gerrit is terrible for actually working with and is unfriendly even to experienced git users. I have to battle with Gerrit to submit patches to MediaWiki and it is a painful process every time.

Clarifying that I believe that my personal off work time is valuable to myself. The more time and friction I have to spend putting in a pull request/code review is the less time I get to myself.

[frogperson]

I don't understand your point of view at all. Gerrit has such a good work flow and ui. It's probably in the top 5 best tools I have ever used. Github's pull request model is like a child's toy in comparison.

[labster]

Gerrit has a good UI? Heh, that's a good one. Git's CLI is like 10x superior to Gerrit's interface, and that's even counting the fact that git checkout does like 2 or 3 different things.

I've basically given up on fighting with the WMF's Gerrit install and outsource the work to other people. I push a commit up to a github repository, open a task, and ask another developer to grab my commit from a new git remote. I want to write code, not wrangle with whatever Gerrit wants me to do to submit code. And then look for tiny links on a cluttered page. No thanks.

[xstartup]

Serious question, what are other best ones?

[ithkuil]

I like https://reviewable.io, low friction github integration but gerrit-like multi-patchsets and generally a sane flow when you have multiple rounds of comments

[vlovich123]

I really enjoyed ReviewBoard when I used it but we built up a lot of tooling around it to actually make it useful & integrate into git.

[u801e]

What is your opinion on just using a pure mailing list workflow (like what's done for git itself)?

[nbsd4lyfe]

I'm assuming you're talking about the reviewer and long term contributor side of it. personally I found initial setup as a drive-by contributor to be very tedious. GitHub is the lowest friction because I already have an account with SSH key etc.

[rajathagasthya]

I've used both and I much prefer Gerrit over Github. I like the multiple patchset workflow, I don't have to deal with fork/opening a PR and I can actually do dependent reviews in Gerrit (if someone knows how to do this in Github, let me know!). I find Github has "too many steps".

[shaan7]

See the comment on the same thread https://github.com/golang/go/issues/18517#issuecomment-27051...

[AndyNemmity]

Honestly, I am the same way. Any project that users gerrit for some reasons takes 10x+ time to merge issues or communicate, and the usability is terrible.

I now just avoid it whenever possible, usually forking my own thing, and just doing what I need.

[alphaIuGN59]

I know there are a lot of code review tools, but with GITHUB and all the tools they make available, I wonder why the other code-review tools are still being developed/maintained.

[TheAceOfHearts]

Other tools are developed and maintained to stimulate competition and avoid vendor lock-in. Monocultures are dangerous.

One example of a use-case where GitHub falls short is offline support: you can't take the issue tracker and wiki with you. There are alternative tools such as fossil [0] which have built-in bug tracking and wiki, which is an attractive feature for some people.

[0] https://fossil-scm.org/

[dtech]

I think you're right about the issue tracker, but the wiki is just another git repo [1] that you can checkout, commit and push.

[1] https://help.github.com/articles/adding-and-editing-wiki-pag...

[alphaIuGN59]

Yeah.. this is one thing I recently discovered. I use github for my personal projects, and was going to start using the issue tracker to keep track of the bugs. But then I realized that if I do that if I do start tracking bugs on github, I will pretty much be tied to github.

Hopefully gitlab or bitbucket comes up with a solution which enables the owners of the repos to move bugs/issue tracking, which will force github to enable this feature as well.

[TheAceOfHearts]

Thanks for sharing. I wasn't aware this feature was available on GitHub.

I like fossil because it's all built-in and can be wrapped up in a single file. But it's always great to have more choices available.

[alphaIuGN59]

I agree 100% that monocultures are dangerous. But too much fragmentation is also harmful.

For example, now we have github, gitlab, mercuirial(bitbucket).. I only use the above 3.. but I am sure I can come up with 100 different github/gitlab type companies.

When there is so much fragmentation, it becomes difficult to find project or code reliably. For example, I have seen certain projects on bitbucket, which are awesome (say `ProjectA`) and create a lot of value. But there exists a very similar but differnt project `ProjectB` on github. Probably the author of `ProjectB` had the same problem that the author of `ProjectA` had, but couldnt discover that `ProjectA` already exists.

What open-source software enables you to do is to reuse software, however, if we create so many distinct places where the code resides, it becomes harder and harder to discover that code. Which leads to recreating codebases over and over again.

thanks for pointing out fossil by the way..

[shurcooL]

You can actually access a mirror of Go’s issue tracker (hosted on GitHub) offline by using a tool [0]. Of course, a lot of code was written to make it possible, and it’s a read-only view.

[0] https://godoc.org/golang.org/x/build/maintner/cmd/maintserve

[not_kurt_godel]

> GITHUB

Off-topic, but I'm genuinely curious why you chose this capitalization?

[majewsky]

I see this fairly often that somehow a group of users collectively decides that a certain name has to be typed in all-caps. Whenever someone asks me a question about SWIFT, I tell them I have no idea about fintech, but I can instead answer any questions they have about Swift. But it's an uphill battle.

(OpenStack Swift, that is, not Apple Swift. And not Suzuki Swift either.)

[_asummers]

My favorite is when people capitalize LISP. It's not 1958 anymore, we can just say Lisp now.

[alphaIuGN59]

No reason really.. Probably unconciouslly highlighted GITHUB :)

[dingo_bat]

My wife often types complete messages in caps. I asked her why she was shouting, and she told me she doesn't consider it shouting at all. To her there's no difference between typing in small letters and all caps.

[skittleson]

I wonder that too. Even competing code review tools are very similar.

[u801e]

The problem I see with Github is the fact that it encourages contributors to commit repeated fixes to a pull request, rather than amending/rebasing the patch set. The other problem that Github has is that it doesn't provide a way to get interdiffs between patchset revisions. That is, if I open a pull request, get some comments, address those comments and rebase my changes in, then there's no way for the reviewer(s) to see what I actually changed.

[kbrobert]

No it does not. This is a myth that is always used by people who want to move to GitHub for other actual reasons that they cannot say in public.

I have first hand information from two projects (one of them large) that contribution, apart from drive-by doc fixes, does not increase.

Meaningful contribution decreases, because existing devs leave or become inactive because of GitHub.

A lot of projects moving to GitHub are in the Gervais-principle stage.

[rajathagasthya]

This obviously increases contributions, which is great. Does this now require more time from people with Run Trybot access to manually kick off a CI run? I wondered why Go always used that instead of automatically kicking off CI for each patchset. To save resources perhaps?

[discardable_dan]

At its heart, I am not certain the increased contributions are always good. There is a lot of theory written about how to build and grow out languages, and most of it seems to indicate that there needs to be a strong, central group of people with veto power. So long as the Go internal team retains this power, it's good, but having a community driving development for itself outside of the core language team often leads to (a) too many cooks in the kitchen and (b) adding features vocal fans want that nobody else cares about.

[rajathagasthya]

Go does have a strong, central group and in my (admittedly little) experience, they're very helpful too. But I'm just curious how the Go team scales with code reviews since this move will certainly bring in an influx of new contributors/PRs.

[bradfitz]

> To save resources perhaps?

For security, mostly. Our isolation is good but not perfect.

We could probably do a smaller set of (secure) builders for all patches, but it hasn't been a priority.

[mcote]

Given that one of the reasons GitHub is so popular is that it's a common toolchain, I wonder if it is indeed obvious that replacing the code-review tool with a different one (not to mention one that is often considered much less intuitive, if not usable) will result in more contributions. I hope the Go team posts some results in a few months.