7 ms·

Go accepts patches from GitHub pull requests now

277 points by vhost- 9y ago

bradfitz 9y ago
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 https://golang.org/wiki/GerritBot Code is at https://github.com/golang/build/blob/master/cmd/gerritbot/gerritbot.go https://github.com/golang/build/blob/master/cmd/gerritbot/ge...
- eloff 9y ago
  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 9y ago
    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 9y ago
      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.
      - xstartup 9y ago
        Serious question, what are other best ones?
        vlovich123 9y ago
        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.
        ithkuil 9y ago
        I like https://reviewable.io https://reviewable.io, low friction github integration but gerrit-like multi-patchsets and generally a sane flow when you have multiple rounds of comments
      - labster 9y ago
        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.
      - nbsd4lyfe 9y ago
        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.
      - 9y ago
    - alphaIuGN59 9y ago
      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.
      - skittleson 9y ago
        I wonder that too. Even competing code review tools are very similar.
      - not_kurt_godel 9y ago
        > GITHUB Off-topic, but I'm genuinely curious why you chose this capitalization?
        dingo_bat 9y ago
        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.
        majewsky 9y ago
        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 9y ago
        My favorite is when people capitalize LISP. It's not 1958 anymore, we can just say Lisp now.
        alphaIuGN59 9y ago
        No reason really.. Probably unconciouslly highlighted GITHUB :)
    - shaan7 9y ago
      See the comment on the same thread https://github.com/golang/go/issues/18517#issuecomment-270518336 https://github.com/golang/go/issues/18517#issuecomment-27051...
    - rajathagasthya 9y ago
      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".
    - AndyNemmity 9y ago
      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.
  - kbrobert 9y ago
    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.
  - u801e 9y ago
    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.
- rajathagasthya 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
    > 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 9y ago
    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.
meddlepal 9y ago
Maybe someone will submit a PR for generics finally.
- deleted 9y ago
  [deleted]
- majewsky 9y ago
  If you think it's so easy to add generics, please go ahead and prove it.
  - meddlepal 9y ago
    What part of my comment suggested it was easy? Are pull requests only for "easy" things in your mind? That said, it's also not rocket science, just about every other statically typed language in existence has figured out how to do it and has had the feature for at least a decade or more. But Go folks keep clinging to this weird view that generics are "hard". You won't see a PR from me. I'm happily ensconced in the JVM (Java, Kotlin) and Rust land these days with the occasional foray into Python here and there.
tejasmanohar 9y ago
This is an excellent change. While Gerrit is undoubtedly more powerful than GitHub's PR, GitHub is easy and familiar. I've found a fair number of small fixes and changes I've wanted to make to Gerrit projects but just abandoned due to not being inline with my current workflow. Now, I'll submit a PR and figure out the rest later. Hopefully, code review still being through Gerrit doesn't mean more stale PRs to deal with though. I guess time will tell...
tombh 9y ago
It seems odd to me that Golang treats Github as a first class citizen for package management, yet a second class citizen for core contributions. I'm really only a dabbler in Golang, so would appreciate any context. For instance I was affected by the recent go-bindata owner change[1]. The Github user deleted their account and some random user reregistered the original user's name and recreated the repo (albeit seemingly innocently to help everyone get their CIs running again). Actually while we're on the subject, Golang's whole package management experience is surprisingly disappointing :/ [1]https://www.reddit.com/r/golang/comments/7vv9zz/popular_lib_gobindata_removed_from_github_or_why/ https://www.reddit.com/r/golang/comments/7vv9zz/popular_lib_...
- pokstad 9y ago
  Go does not treat Github any differently than any other VCS provider when it comes to package management. OG gophers vendor their deps into their repo and avoid creating dependencies on 3rd party code whenever possible. The Go stdlib is very full featured so it is not unrealistic. The problem with the go-bindata could be avoided by always vendoring/forking your deps and never trust any VCS provider (e.g. GitHub, Bitbucket, source forge) to handle your critical dependency needs.
  - heinrich5991 9y ago
    Go does have special handling for Github: https://github.com/golang/go/blob/816154b06553a4cf8ee7ad089f5e444b37bed43d/src/cmd/go/internal/get/vcs.go#L953-L961 https://github.com/golang/go/blob/816154b06553a4cf8ee7ad089f....
    - Vendan 9y ago
      Except that that link also shows special handling for 5 other VCS hosts, and you can have your own website given the same special handling by putting meta tags in the html. Github is not given special handling that no other VCS host is allowed.
- joerichey 9y ago
  Take a look at the dep[1] tool. It allows you to ship your project with all of its dependencies included. This means that only your source is needed to build your application/package. The Gopkg.toml/Gopkg.lock files in dep are quite similar to Rust's Cargo.toml/Cargo.lock files. I think it's a good move as Rust has probably the best package management story out there. Also, as the other comment mentioned, github.com is not "special" in any way. Any website with a git repo will work just as well. In fact, some key libraries are served from golang.org/x/<whatever>[2] not github.com. [1]https://github.com/golang/dep https://github.com/golang/dep [2]https://github.com/golang/go/wiki/SubRepositories https://github.com/golang/go/wiki/SubRepositories
Bumppy 9y ago
very nice..http://www.bumppy.com/ http://www.bumppy.com/
mgbmtl 9y ago
Slightly off topic, but would anyone have a similar solution/experience to sync between GitHub and Gitlab? (community version, not EE, since this is for a Free Software project)
- connorshea 9y ago
  Mirroring is an Enterprise Edition feature but there are probably ways to hack around that.
nbsd4lyfe 9y ago
I'm still putting off contributions because the CLA signing mechanism asked me for my phone number.
shabbyrobe 9y ago
Great to see the high-friction barriers falling. The move to Github for issues has been a massive improvement. Hopefully they can do something about getting rid of Google groups now. It's an extraordinarily poor organ of record. The low-friction Github issue tracker is full to bursting with high-ranking results for things that amount to support requests, but the pat response is a slightly-too-curt "ask this on golang-nuts, closed, kthxbye", and that's where the trail ends.
- shabbyrobe 9y ago
  https://github.com/golang/go/issues/23745 https://github.com/golang/go/issues/23745
flavio81 9y ago
Golang accepting patches? Great! Let's see if somebody adds * generics * elegant exception handling * sum types * (optional) compile-time metaprogramming or at the very least, automatic, transparent, implicit templating. Seriously. It would be great.

277 points by vhost- 9y ago

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 https://golang.org/wiki/GerritBot Code is at https://github.com/golang/build/blob/master/cmd/gerritbot/gerritbot.go https://github.com/golang/build/blob/master/cmd/gerritbot/ge...

eloff 9y ago
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 9y ago
  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 9y ago
    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.
    - xstartup 9y ago
      Serious question, what are other best ones?
      - vlovich123 9y ago
        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.
      - ithkuil 9y ago
        I like https://reviewable.io https://reviewable.io, low friction github integration but gerrit-like multi-patchsets and generally a sane flow when you have multiple rounds of comments
    - labster 9y ago
      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.
    - nbsd4lyfe 9y ago
      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.
    - 9y ago
  - alphaIuGN59 9y ago
    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.
    - skittleson 9y ago
      I wonder that too. Even competing code review tools are very similar.
    - not_kurt_godel 9y ago
      > GITHUB Off-topic, but I'm genuinely curious why you chose this capitalization?
      - dingo_bat 9y ago
        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.
      - majewsky 9y ago
        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 9y ago
        My favorite is when people capitalize LISP. It's not 1958 anymore, we can just say Lisp now.
      - alphaIuGN59 9y ago
        No reason really.. Probably unconciouslly highlighted GITHUB :)
  - shaan7 9y ago
    See the comment on the same thread https://github.com/golang/go/issues/18517#issuecomment-270518336 https://github.com/golang/go/issues/18517#issuecomment-27051...
  - rajathagasthya 9y ago
    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".
  - AndyNemmity 9y ago
    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.
- kbrobert 9y ago
  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.
- u801e 9y ago
  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.
rajathagasthya 9y ago
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 9y ago
  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 9y ago
    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 9y ago
  > 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 9y ago
  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.

meddlepal 9y ago

Maybe someone will submit a PR for generics finally.

deleted 9y ago
[deleted]
majewsky 9y ago
If you think it's so easy to add generics, please go ahead and prove it.
- meddlepal 9y ago
  What part of my comment suggested it was easy? Are pull requests only for "easy" things in your mind? That said, it's also not rocket science, just about every other statically typed language in existence has figured out how to do it and has had the feature for at least a decade or more. But Go folks keep clinging to this weird view that generics are "hard". You won't see a PR from me. I'm happily ensconced in the JVM (Java, Kotlin) and Rust land these days with the occasional foray into Python here and there.

tejasmanohar 9y ago

This is an excellent change. While Gerrit is undoubtedly more powerful than GitHub's PR, GitHub is easy and familiar. I've found a fair number of small fixes and changes I've wanted to make to Gerrit projects but just abandoned due to not being inline with my current workflow. Now, I'll submit a PR and figure out the rest later. Hopefully, code review still being through Gerrit doesn't mean more stale PRs to deal with though. I guess time will tell...

tombh 9y ago

It seems odd to me that Golang treats Github as a first class citizen for package management, yet a second class citizen for core contributions. I'm really only a dabbler in Golang, so would appreciate any context. For instance I was affected by the recent go-bindata owner change[1]. The Github user deleted their account and some random user reregistered the original user's name and recreated the repo (albeit seemingly innocently to help everyone get their CIs running again). Actually while we're on the subject, Golang's whole package management experience is surprisingly disappointing :/ [1]https://www.reddit.com/r/golang/comments/7vv9zz/popular_lib_gobindata_removed_from_github_or_why/ https://www.reddit.com/r/golang/comments/7vv9zz/popular_lib_...

pokstad 9y ago
Go does not treat Github any differently than any other VCS provider when it comes to package management. OG gophers vendor their deps into their repo and avoid creating dependencies on 3rd party code whenever possible. The Go stdlib is very full featured so it is not unrealistic. The problem with the go-bindata could be avoided by always vendoring/forking your deps and never trust any VCS provider (e.g. GitHub, Bitbucket, source forge) to handle your critical dependency needs.
- heinrich5991 9y ago
  Go does have special handling for Github: https://github.com/golang/go/blob/816154b06553a4cf8ee7ad089f5e444b37bed43d/src/cmd/go/internal/get/vcs.go#L953-L961 https://github.com/golang/go/blob/816154b06553a4cf8ee7ad089f....
  - Vendan 9y ago
    Except that that link also shows special handling for 5 other VCS hosts, and you can have your own website given the same special handling by putting meta tags in the html. Github is not given special handling that no other VCS host is allowed.
joerichey 9y ago
Take a look at the dep[1] tool. It allows you to ship your project with all of its dependencies included. This means that only your source is needed to build your application/package. The Gopkg.toml/Gopkg.lock files in dep are quite similar to Rust's Cargo.toml/Cargo.lock files. I think it's a good move as Rust has probably the best package management story out there. Also, as the other comment mentioned, github.com is not "special" in any way. Any website with a git repo will work just as well. In fact, some key libraries are served from golang.org/x/<whatever>[2] not github.com. [1]https://github.com/golang/dep https://github.com/golang/dep [2]https://github.com/golang/go/wiki/SubRepositories https://github.com/golang/go/wiki/SubRepositories

Bumppy 9y ago

very nice..http://www.bumppy.com/ http://www.bumppy.com/

mgbmtl 9y ago

Slightly off topic, but would anyone have a similar solution/experience to sync between GitHub and Gitlab? (community version, not EE, since this is for a Free Software project)

connorshea 9y ago
Mirroring is an Enterprise Edition feature but there are probably ways to hack around that.

nbsd4lyfe 9y ago

I'm still putting off contributions because the CLA signing mechanism asked me for my phone number.

shabbyrobe 9y ago

Great to see the high-friction barriers falling. The move to Github for issues has been a massive improvement. Hopefully they can do something about getting rid of Google groups now. It's an extraordinarily poor organ of record. The low-friction Github issue tracker is full to bursting with high-ranking results for things that amount to support requests, but the pat response is a slightly-too-curt "ask this on golang-nuts, closed, kthxbye", and that's where the trail ends.

shabbyrobe 9y ago
https://github.com/golang/go/issues/23745 https://github.com/golang/go/issues/23745

flavio81 9y ago

Golang accepting patches? Great! Let's see if somebody adds * generics * elegant exception handling * sum types * (optional) compile-time metaprogramming or at the very least, automatic, transparent, implicit templating. Seriously. It would be great.