4 ms·

Codereview: Should the Go project stop importing GitHub PRs?

30 points by nateb2022 3y ago

amgate 3y ago
[dead]
PossiblyKyle 3y ago
Admittedly I don’t have experience contributing to FOSS projects (yet), but like many companies we use the feature branch workflow, and have minimal conflicts; both on tasks and in the code itself. The reason is (and I’m stating the somewhat obvious) that we have engineering managers whose primary job is coordinating the tasks between teams and within each team. This is done externally via Jira, and to me it reflects on a weak spot of GitHub if it wants to be “the place to manage a project” - it’s good for managing a code base but lacks the tools to manage it as a project/product.
- madeofpalk 3y ago
  GitHub has been working on this recently and made pretty significant improvements with the new Org Projects and Tasklists in issues. Project management for my day job happens entirely in GitHub and while it’s not perfect, it’s significantly better than it was even 12 months ago.
TheBrokenRail 3y ago
I've never contributed to Go before, but from reading this, I have to wonder who thought this system was a good idea. From the sounds of it, the only situation where this PR-mirroring works properly, is PRs without any comments, which I imagine are quite rare. But if your PR does have comments, then you not only have to sign up for Gerrit anyways, but you're also responsible for keeping the GitHub PR and Gerrit PR in sync. That sounds horrible.
- reichstein 3y ago
  There are tools to automatically update the Gerrit change when the GitHub PR is updated. If you keep the comments on GitHub, eventually you may end up with an acceptable PR, which you have continuously tested in Gerrit too. Then you just land that. If you want to do the reviews in Gerrit, then that's more annoying, but the changes can still be made on GitHub.
laurels-marts 3y ago
What is Gerrit and why are they using it instead of just using GitHub?
- natebc 3y ago
  https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html It's a code review platform used heavily by Google.
  - laurels-marts 3y ago
    If it's closed-source project store it in whatever proprietary platform you want. But if it's open-source and you want contributors the just do everyone a favour and use the de-facto platform.
    - bqmjjx0kac 3y ago
      Gerrit is significantly nicer to use. It keeps track of each patch set you upload and lets you diff between them. GitHub seems to just... forget about everything but the two most recent uploads.
    - danpalmer 3y ago
      I see your point, but some of the biggest open source projects don’t use the GitHub workflow: Chromium, Linux, Go, Android, and so on. The GitHub workflow is great for many projects but doesn’t really scale to thousands of contributors, every large project on GitHub (e.g. Kubernetes, VSCode) end up with loads of tooling, loads of pain, and a bad experience for contributors and maintainers. Also Gerrit isn’t proprietary. It’s git for the VCS and gerrit is just a web app on top of that. It just works in a different model to GitHub.
    - TheDong 3y ago
      The linux kernel, which is open source and does want contributors, is doing more-or-less just fine with an email-based PR and review flow. If it's an open source project, it should be using an open source review platform that allows improvements and specialization of the code hosting too. Using github, where the review tools are bad and can't be improved by an outsider, is a slap in the face to open source. Frankly, I'm tired of people using github. The fact that it still doesn't have any idea of patchsets and diffs between them is cripplingly bad (i.e. you force push a new version of your change, there's no easy way to review the diff between the old and new version of your change). Having to use yet more third party tools, like https://reviewable.io https://reviewable.io, isn't an answer to this, it's just a sign that github should be open source so these could be forks or first-party tools. It's also just insulting for an open source project to force people to use a proprietary platform owned by microsoft.
codeapprove 3y ago
Even at Google, most people find Gerrit to be pretty intimidating. It’s mostly only used for Chrome, Go, and Android and it’s far behind Google’s flagship review tool (Critique). Gerrit is not a bad tool but it is somewhat hard to get used to if you have the more common GitHub-flavored git experience that most software engineers have these days. I expect if the goal is to get the most vibrant contributor community possible the best thing would be to move to a GitHub-first workflow where Gerrit is supported as a backup. But there’s too much inertia for that to ever happen.
- aseipp 3y ago
  Honestly, I really think Gerrit would be so much better if it weren't for the UI being so... compact? I think it's actually got good information, and a review tool is something many people spend tons of time in, so power-user proficiency is important. But the density is wrong, and I feel it makes it more cluttered than necessary, and that drives people away? Here's a good example of what I mean, taking a change from ChromiumOS's Gerrit versus a random patch on Phorge (a fork of Phabricator which uses a similar workflow): - https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4228112 https://chromium-review.googlesource.com/c/chromiumos/third_... - https://we.phorge.it/D25332 https://we.phorge.it/D25332 The Gerrit one is really busy in my opinion, while the Phorge one gives the page a lot more breathing room, which I think just makes viewing it much easier and less intimidating. Despite that Phorge is still good for power users: it shows all the needed information, has hotkey shortcuts for fast navigation, nice diff viewer, nice side panel with all diffs listed, etc. I'm trying to set up Gerrit right now and the really compact UI is honestly my main complaint. Maybe someone who's better at UI/UX can give more refined comparison or analysis, but the nice, "bigger" design of Phabricator/Phorge's diff viewer is something I really miss. (I also like the "untabbed" design of Phorge, contra GitHub; all the comments, changes, and code is on one page, instead of having to click back and forth between comments and diffs.)
- drycode 3y ago
  I was working on the Fuschia project at Google and we used Gerrit as well. It definitely took some getting used to, but once I got the hang of it I found it to be a much better review tool. It was a lot easier to show how contributions stacked, to continue iterating on a “branch” while waiting for a review from the team, and worked better with trunk-based development workflows.
thcipriani 3y ago
This has come up for Wikimedia's Gerrit, too[0]. Wikimedia opts to close PRs with a message saying (tl;dr): this is a read-only mirror, contribute via Gerrit. Importing from GitHub seems like it might be a bad experience except for drive-by commits (which are valuable and Wikimedia misses out on). Mirroring to GitHub is sensible—(1) Dependabot (2) Nice code browser (3) this is a perk of working on open projects: your name shows up in GitHub (the default place for open source developers) next to the project. But there's no trivial way to make it clear for developers that your repo is a mirror (outside of the description). It would be nice if there were a button in the UI to make it clear a mirror is a mirror (e.g., to show up in searches for `mirror:true`[1]). It seems like this requires Special Privileges™ somewhere... [0]: <https://phabricator.wikimedia.org/T37497 https://phabricator.wikimedia.org/T37497> [1]: <https://github.com/search?q=mirror%3Atrue&type=repositories https://github.com/search?q=mirror%3Atrue&type=repositories>
eliben 3y ago
I love GitHub but I sure wish its code review functionality was much, much better. Doing complex code reviews is really painful.
- codeapprove 3y ago
  I’m obviously biased but you might like https://codeapprove.com https://codeapprove.com, it’s a GitHub-compatible code review UI for power users. There are actually a lot of good options in the space these days (Reviewable, Graphite, etc) so there’s no much reason to stick with what GitHub gives you!

30 points by nateb2022 3y ago

[dead]

Admittedly I don’t have experience contributing to FOSS projects (yet), but like many companies we use the feature branch workflow, and have minimal conflicts; both on tasks and in the code itself. The reason is (and I’m stating the somewhat obvious) that we have engineering managers whose primary job is coordinating the tasks between teams and within each team. This is done externally via Jira, and to me it reflects on a weak spot of GitHub if it wants to be “the place to manage a project” - it’s good for managing a code base but lacks the tools to manage it as a project/product.

madeofpalk 3y ago
GitHub has been working on this recently and made pretty significant improvements with the new Org Projects and Tasklists in issues. Project management for my day job happens entirely in GitHub and while it’s not perfect, it’s significantly better than it was even 12 months ago.

TheBrokenRail 3y ago

I've never contributed to Go before, but from reading this, I have to wonder who thought this system was a good idea. From the sounds of it, the only situation where this PR-mirroring works properly, is PRs without any comments, which I imagine are quite rare. But if your PR does have comments, then you not only have to sign up for Gerrit anyways, but you're also responsible for keeping the GitHub PR and Gerrit PR in sync. That sounds horrible.

reichstein 3y ago
There are tools to automatically update the Gerrit change when the GitHub PR is updated. If you keep the comments on GitHub, eventually you may end up with an acceptable PR, which you have continuously tested in Gerrit too. Then you just land that. If you want to do the reviews in Gerrit, then that's more annoying, but the changes can still be made on GitHub.

laurels-marts 3y ago

What is Gerrit and why are they using it instead of just using GitHub?

natebc 3y ago
https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html It's a code review platform used heavily by Google.
- laurels-marts 3y ago
  If it's closed-source project store it in whatever proprietary platform you want. But if it's open-source and you want contributors the just do everyone a favour and use the de-facto platform.
  - bqmjjx0kac 3y ago
    Gerrit is significantly nicer to use. It keeps track of each patch set you upload and lets you diff between them. GitHub seems to just... forget about everything but the two most recent uploads.
  - danpalmer 3y ago
    I see your point, but some of the biggest open source projects don’t use the GitHub workflow: Chromium, Linux, Go, Android, and so on. The GitHub workflow is great for many projects but doesn’t really scale to thousands of contributors, every large project on GitHub (e.g. Kubernetes, VSCode) end up with loads of tooling, loads of pain, and a bad experience for contributors and maintainers. Also Gerrit isn’t proprietary. It’s git for the VCS and gerrit is just a web app on top of that. It just works in a different model to GitHub.
  - TheDong 3y ago
    The linux kernel, which is open source and does want contributors, is doing more-or-less just fine with an email-based PR and review flow. If it's an open source project, it should be using an open source review platform that allows improvements and specialization of the code hosting too. Using github, where the review tools are bad and can't be improved by an outsider, is a slap in the face to open source. Frankly, I'm tired of people using github. The fact that it still doesn't have any idea of patchsets and diffs between them is cripplingly bad (i.e. you force push a new version of your change, there's no easy way to review the diff between the old and new version of your change). Having to use yet more third party tools, like https://reviewable.io https://reviewable.io, isn't an answer to this, it's just a sign that github should be open source so these could be forks or first-party tools. It's also just insulting for an open source project to force people to use a proprietary platform owned by microsoft.

codeapprove 3y ago

Even at Google, most people find Gerrit to be pretty intimidating. It’s mostly only used for Chrome, Go, and Android and it’s far behind Google’s flagship review tool (Critique). Gerrit is not a bad tool but it is somewhat hard to get used to if you have the more common GitHub-flavored git experience that most software engineers have these days. I expect if the goal is to get the most vibrant contributor community possible the best thing would be to move to a GitHub-first workflow where Gerrit is supported as a backup. But there’s too much inertia for that to ever happen.

aseipp 3y ago
Honestly, I really think Gerrit would be so much better if it weren't for the UI being so... compact? I think it's actually got good information, and a review tool is something many people spend tons of time in, so power-user proficiency is important. But the density is wrong, and I feel it makes it more cluttered than necessary, and that drives people away? Here's a good example of what I mean, taking a change from ChromiumOS's Gerrit versus a random patch on Phorge (a fork of Phabricator which uses a similar workflow): - https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4228112 https://chromium-review.googlesource.com/c/chromiumos/third_... - https://we.phorge.it/D25332 https://we.phorge.it/D25332 The Gerrit one is really busy in my opinion, while the Phorge one gives the page a lot more breathing room, which I think just makes viewing it much easier and less intimidating. Despite that Phorge is still good for power users: it shows all the needed information, has hotkey shortcuts for fast navigation, nice diff viewer, nice side panel with all diffs listed, etc. I'm trying to set up Gerrit right now and the really compact UI is honestly my main complaint. Maybe someone who's better at UI/UX can give more refined comparison or analysis, but the nice, "bigger" design of Phabricator/Phorge's diff viewer is something I really miss. (I also like the "untabbed" design of Phorge, contra GitHub; all the comments, changes, and code is on one page, instead of having to click back and forth between comments and diffs.)
drycode 3y ago
I was working on the Fuschia project at Google and we used Gerrit as well. It definitely took some getting used to, but once I got the hang of it I found it to be a much better review tool. It was a lot easier to show how contributions stacked, to continue iterating on a “branch” while waiting for a review from the team, and worked better with trunk-based development workflows.

thcipriani 3y ago

This has come up for Wikimedia's Gerrit, too[0]. Wikimedia opts to close PRs with a message saying (tl;dr): this is a read-only mirror, contribute via Gerrit. Importing from GitHub seems like it might be a bad experience except for drive-by commits (which are valuable and Wikimedia misses out on). Mirroring to GitHub is sensible—(1) Dependabot (2) Nice code browser (3) this is a perk of working on open projects: your name shows up in GitHub (the default place for open source developers) next to the project. But there's no trivial way to make it clear for developers that your repo is a mirror (outside of the description). It would be nice if there were a button in the UI to make it clear a mirror is a mirror (e.g., to show up in searches for `mirror:true`[1]). It seems like this requires Special Privileges™ somewhere... [0]: <https://phabricator.wikimedia.org/T37497 https://phabricator.wikimedia.org/T37497> [1]: <https://github.com/search?q=mirror%3Atrue&type=repositories https://github.com/search?q=mirror%3Atrue&type=repositories>

eliben 3y ago

I love GitHub but I sure wish its code review functionality was much, much better. Doing complex code reviews is really painful.

codeapprove 3y ago
I’m obviously biased but you might like https://codeapprove.com https://codeapprove.com, it’s a GitHub-compatible code review UI for power users. There are actually a lot of good options in the space these days (Reviewable, Graphite, etc) so there’s no much reason to stick with what GitHub gives you!