https://github.com/golang/go/discussions/61182 Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Case Studies + Customer Stories + Resources * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing [ ] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this organization All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. {{ message }} golang / go Public * Notifications * Fork 16.8k * Star 113k * Code * Issues 5k+ * Pull requests 365 * Discussions * Actions * Projects 4 * Wiki * Security * Insights More * Code * Issues * Pull requests * Discussions * Actions * Projects * Wiki * Security * Insights codereview: should the Go project stop importing GitHub PRs? #61182 bcmills announced in Discussions codereview: should the Go project stop importing GitHub PRs? #61182 @bcmills bcmills Jul 5, 2023 * 6 comments * 11 replies Return to top Discussion options * {{title}} Something went wrong. Quote reply [520] bcmills Jul 5, 2023 Maintainer - In #18517 (accepted Jan. 2017), we decided to start importing GitHub pull requests for the Go repositories as Gerrit changes, in addition to our more typical direct-to-Gerrit workflow. In the time since then, I have reviewed many contributed changes to the various Go repos, including those posted as GitHub PRs and those posted directly to Gerrit. In my experience, the GitHub workflow is not working well. * Since most changes receive at least one comment that needs to be addressed, contributors will almost always need to figure out how to sign in to Gerrit and use it anyway. + A significant fraction of GitHub PRs are abandoned when the author does not respond to Gerrit comments, but the existence of an open PR discourages other contributors from working on the corresponding issue. * Mismatches between the GitHub and Gerrit data models introduce confusion. + Gerrit squashes all commits for the PR into a single Gerrit commit, and as a result forces users to edit commit messages by editing the PR title and comment, which does not seem to be intuitive or discoverable for most users. See: o x/build/cmd/gerritbot: commit message source confuses a lot of people #25359 o wiki: Improve GerritBot GitHub PR workflow instructions # 30564 o x/build/cmd/gerritbot: should determine author from first commit rather not last #38957 o x/build/cmd/gerritbot: support multiple CL authors (Co-authored-by) #40906 o x/build/cmd/gerritbot: auto-wrap description #24832 + Gerrit comments are not copied back to the GitHub PR (instead the bot leaves a comment with a Gerrit link), so a large fraction of code reviews for GitHub PRs require multiple rounds of comments of the form "please mark comments as resolved in Gerrit if they have been addressed", and the status of PRs with unresolved Gerrit comments is often unclear. o See x/build/cmd/gerritbot: inline comments not synchronized to GitHub #38689. + The Go git-codereview hooks do not apply for GitHub PRs, so simple reminder steps like "make sure your code is gofmt'd" often require extra rounds of review comments. o See x/build/cmd/gerritbot: perform gofmt checks before pushing to Gerrit #24946. * Once a change has been initiated via a GitHub PR, it isn't possible to switch to the more direct Gerrit workflow, and isn't possible to reopen the GitHub PR once it is closed. See: + x/build/cmd/gerritbot: Gerrit edits are immediately overwritten by older GitHub commits #24887 + x/build/cmd/gerritbot: support continuing to work with PRs that are closed and re-opened #40874 * Since the Gerrit workflow is so different from the GitHub one, the GitHub import process does not do much in the way of helping new contributors develop familiarity for longer-term contributions on the project. In addition, the bot that implements the import workflow is somewhat buggy and not always reliable (see https://github.com/golang/go/issues?q= is%3Aissue+is%3Aopen+gerritbot+in%3Atitle for the complete list). It may be possible to fix many of the bugs in the GerritBot implementation, at some indeterminate cost. However, I do not believe that it is possible to address the mismatches in the data model in a satisfactory way -- especially not without significant additional development work on GerritBot, which I don't foresee becoming a priority for the Go project in the near future. In this discussion, I would like to investigate the possibility of no longer accepting GitHub PRs, and reducing GerritBot to simply closing them with a message directing the requester to the Gerrit workflow in the Contribution Guide. That would essentially reverse #18517 in light of several years' experience with the result of that proposal. Beta Was this translation helpful? Give feedback. 6 You must be logged in to vote 28 11 6 All reactions * 28 * 11 * 6 Replies: 6 comments * 11 replies * Oldest * Newest * Top Comment options * {{title}} Something went wrong. Quote reply [865] achille-roussel Jul 5, 2023 - I started contributing to Go a few months ago and used the Github workflow on my first submission. The especially difficult part was getting formatting conventions right on the commit message: sending updates that rendered differently on Github to match the required format for Gerrit took most of the time. In hindsight, learning the Gerrit workflow from the start would have been much simpler. Beta Was this translation helpful? Give feedback. 1 You must be logged in to vote [?] 4 All reactions * [?] 4 1 reply @ncruces Comment options * {{title}} Something went wrong. Quote reply ncruces Jul 5, 2023 - I agree with this, and having been forced to do Gerrit extensively (professionally), I also wished I went with Gerrit from the get go. Yet, I still think GitHub import lowers the bar. If simple reviews of drive-by contributions could be handled GitHub-side, that would be great. Unless those are mostly considered noise. Beta Was this translation helpful? Give feedback. All reactions Comment options * {{title}} Something went wrong. Quote reply [725] SuperSandro2000 Jul 5, 2023 - From my experience contributing to projects hosted on external services is usually cumbersome because it requires extra account registration and small drive by contributions like link fixes are probably not being done anymore. Beta Was this translation helpful? Give feedback. 11 You must be logged in to vote 1 All reactions * 1 6 replies Show 1 previous reply @bcmills Comment options * {{title}} Something went wrong. Quote reply edited * {{editor}}'s edit {{actor}} deleted this content . {{editor}}'s edit Something went wrong. bcmills Jul 5, 2023 Maintainer Author - (And when you author a PR, it's hard to predict ahead of time whether it will be merged without any comments to resolve.) Beta Was this translation helpful? Give feedback. All reactions @mooijtech Comment options * {{title}} Something went wrong. Quote reply mooijtech Jul 5, 2023 - Much prefer using GitHub for everything as it makes contributing for others easier. Beta Was this translation helpful? Give feedback. 6 All reactions * 6 @bcmills Comment options * {{title}} Something went wrong. Quote reply bcmills Jul 5, 2023 Maintainer Author - @mooijtech, "using GitHub for everything" was considered (and declined) in #21956. Beta Was this translation helpful? Give feedback. 1 All reactions * 1 @matys1 Comment options * {{title}} Something went wrong. Quote reply matys1 Jul 5, 2023 - @bcmills that proposal had a lot of upvotes. Why was it declined? This is the opposite of that. Beta Was this translation helpful? Give feedback. 1 All reactions * 1 @bcmills Comment options * {{title}} Something went wrong. Quote reply bcmills Jul 5, 2023 Maintainer Author - @matys1, you can read the discussion on that proposal for the details. Beta Was this translation helpful? Give feedback. 2 All reactions * 2 Comment options * {{title}} Something went wrong. Quote reply [357] mvdan Jul 5, 2023 Collaborator - One data point from another project: we also use Gerrit in the CUE project, and we also allow GitHub PRs for convenience, but in a slightly different way to what Go does currently. We do the code review and CI on the GitHub side, and manually import to Gerrit only when a PR is approved and ready to be merged. This approach is still far from perfect, but we think it works a bit better for PR contributors, since their workflow remains pretty natural. The only difference is that we can't and won't merge the PR directly, since the GitHub repository is simply a mirror from Gerrit. On our side it's a little bit more work, since we effectively review code on two platforms, even if Gerrit is the primary one. However, most of us are already used to doing reviews on GitHub, even with its shortcomings. And one could argue that we save work by not having to maintain any form of server or bot to make this all happen; we simply have an importpr command when a PR is ready to be imported and merged. It's worth noting that using Gerrit directly is still best in most cases, particularly when someone wants to contribute a big or complex change, or when someone wants to contribute regularly. For those cases, we still kindly ask the person to learn the Gerrit route, and I think that's fine. Beta Was this translation helpful? Give feedback. 2 You must be logged in to vote 4 All reactions * 4 2 replies @rsc Comment options * {{title}} Something went wrong. Quote reply rsc Jul 5, 2023 Maintainer - That's an interesting choice. For Go, I do not want the core reviewers (both inside and outside Google) to need to become expert at both GitHub and Gerrit for reviews. We should have just one, and for a variety of very good reasons, that one is Gerrit. Beta Was this translation helpful? Give feedback. All reactions @mvdan Comment options * {{title}} Something went wrong. Quote reply mvdan Jul 5, 2023 Collaborator - I should clarify that we don't guarantee to be able to accept any change as a PR. For example, if a PR is opened with changes to the core evaluator, whose maintainer is Marcel, we'll likely have to ask them to reopen on Gerrit instead since he can't really do code reviews on GitHub. At least from the experience we've had in the past couple of years, most of the PRs we do get we are able to review on GitHub, since they tend to be on the small side and most of the reviewers are capable enough with the platform. Beta Was this translation helpful? Give feedback. 1 All reactions * 1 Comment options * {{title}} Something went wrong. Quote reply [254] Jacalz Jul 5, 2023 - I contributed my first (and currently only) change to the Go project through GitHub a few years back when I was a relatively fresh developer. There were definitely a few quirks with the workflow and I remember having various issues getting titles and commit messages updated but it turned out well in the end. In hindsight, I don't think I would have considered contributing if it wasn't already possible though a service like GitHub where I already felt confident in the tooling. Even to this day I feel similarly about various other projects that are not on GitHub or GitLab (especially using mailing lists, phabicator, etc.) because the step up in learning might not be worth it if I don't want (or have the time) to become a regular contributor. That being said, I could consider contributing through Gerrit in the future because I already have some minor knowledge of how it works from last time (and I care about the project enough). Removing the support for importing PRs from GitHub would likely result in less new developers contributing to the project. There do however seem to be a vast majority of problems with how it is currently done and I believe that the best solution would be to improve the PR workflow through GitHub, if possible. If not, I would not personally be against removing the support as the current cons seem to outweigh the pros in many ways. Beta Was this translation helpful? Give feedback. 2 You must be logged in to vote 1 [?] 4 All reactions * 1 * [?] 4 0 replies Comment options * {{title}} Something went wrong. Quote reply [129] prattmic Jul 5, 2023 Maintainer - I think it would be nice to have some measurement of the review friction mentioned above; "a large fraction of code reviews for GitHub PRs require multiple rounds of comments of the form "please mark comments as resolved in Gerrit if they have been addressed"", etc. I started such an analysis tool in https://go.dev/cl/507907, which could be extended to look at how many back-and-forth comments GitHub pull requests have. As I put this together quickly, I only looked at the proportion of merged CLs, which is indeed lower with GitHub, even for "new" contributors: 2023/07/05 17:11:26 GitHub: 2023/07/05 17:11:26 Total: 1277 2023/07/05 17:11:26 Merged: 438 (34.299139%) 2023/07/05 17:11:26 Native: 2023/07/05 17:11:26 Total: 8671 2023/07/05 17:11:26 Merged: 6783 (78.226271%) 2023/07/05 17:11:26 GitHub (<20 contributions): 2023/07/05 17:11:26 Total: 1094 2023/07/05 17:11:26 Merged: 333 (30.438757%) 2023/07/05 17:11:26 Native (<20 contributions): 2023/07/05 17:11:26 Total: 1148 2023/07/05 17:11:26 Merged: 658 (57.317073%) (This tool suspiciously "finished" fetching at exactly 10000 CLs, so I think I hit a Gerrit limit rather than actually analyzing all CLs). Beta Was this translation helpful? Give feedback. 1 You must be logged in to vote 1 All reactions * 1 2 replies @prattmic Comment options * {{title}} Something went wrong. Quote reply prattmic Jul 5, 2023 Maintainer - On the other hand, this data shows that nearly 50% of CLs from "new" contributors are coming from GitHub, and ~33% of merged "new" contributor CLs. Beta Was this translation helpful? Give feedback. 1 All reactions * 1 @bcmills Comment options * {{title}} Something went wrong. Quote reply bcmills Jul 5, 2023 Maintainer Author - Yep, but that also doesn't tell us what would have happened without GitHub import -- we unfortunately can't measure what fraction of those contributor CLs would have been sent directly through Gerrit vs. not sent at all. Beta Was this translation helpful? Give feedback. 1 All reactions * 1 Comment options * {{title}} Something went wrong. Quote reply [305] deefdragon Jul 5, 2023 - In another thread, @bcmills referenced #21956 "Just use github for everything" as declined. The issue however, was closed with "This issue is too large and diverse to usefully tackle either of those proposals, so I am going to close this issue. Thanks for everyone's input.". Not that it was declined. Just that it was off-track. (this was before the proposal processes) Regarding that proposal, I think the amount of discussion that it received, and the number of people who it means that a large portion of people would prefer using GitHub. I suspect that still rings true today. A key thing that was supposed to happen from that issue was the documentation of the key differences (#22002) between gerrit and github and what the community wanted from its contributing/reviewing experience. That was ultimately closed due to the creation of the very bot of this discussion. I think #22002 should be re-opened/ recreated and done first, and only then a more general decision had regarding how to improve PRs and contributions in general (where using Github vs Gerrit vs both could be discussed). Should the discussion there decide that gerrit is the only solution, the bot can be removed. As it stands, I believe this discussion is suggesting a solution to a premature question. Beta Was this translation helpful? Give feedback. 5 You must be logged in to vote 2 All reactions * 2 0 replies Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Category Discussions Labels None yet 11 participants @bcmills @rsc @achille-roussel @prattmic @deefdragon @mvdan @ncruces @SuperSandro2000 @Jacalz @mooijtech @matys1 Add heading text Add bold text, Add italic text, Add a quote, Add code, Insert Link Link Text [ ] URL [ ] Add Add a link, Add a bulleted list, Add a numbered list, Add a task list, Directly mention a user or team Reference an issue or pull request Add heading text Add bold text, Add italic text, Add a bulleted list, Add a numbered list, Add a task list, 1 reacted with thumbs up emoji 1 reacted with thumbs down emoji 1 reacted with laugh emoji 1 reacted with hooray emoji 1 reacted with confused emoji [?] 1 reacted with heart emoji 1 reacted with rocket emoji 1 reacted with eyes emoji Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time.