Codereview: Should the Go project stop importing GitHub PRs? | Hacker News Reader

Codereview: Should the Go project stop importing GitHub PRs?

github.com

30 pointsnateb202223 comments

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.

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

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

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.

(Opinions are my own)

Gerrit seems to have a lot of extra features in it that make it extra confusing to me. Critique has a lot of features but all of them feel more like intuitive extensions on top of a code review platform (ex: attention set https://abseil.io/resources/swe-book/html/ch19.html). Gerrit seems to have a lot more going on in a much smaller (cramped IMO) UI.

interesting! i find gerrit to be much more enjoyable and find github's PR system inferior.I was also thinking of offering simple gerrit based system for gerrit refugees who left the company and don't want to use github pr for reviewing.

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.

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.

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

https://www.gerritcodereview.com/about.html

It's a code review platform used heavily by Google.

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.

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.

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.

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

But gerrit is open source, not proprietary. In fact, github is a proprietary platform that we shouldn't make essential to FOSS projects.

Gerrit is a Google-built tool for code review that has UX similar to their internal code review tool Critique. I prefer to use Gerrit because, frankly, GitHub code review is awful.

1. As an author, responding to review feedback is a back-and-forth between my editor and the code review tool. I tend to write responses to comments while I edit code. When I'm satisfied and I've pushed my new code, I want to send all of the responses at once -- especially if two responses depend on each other. GitHub doesn't let me draft responses and then send all (unless I let the responses hang in the HTML input, which is risky).

2. On GitHub, there is no great way to update a PR with changes. Yes, I could push a new commit to the branch. But then I need to squash commits (I don't want the "bad" commits to land in main). When GitHub squashes commits, it concatenates the commit messages which is NOT what I want. (I care about my commit messages being precise and accurate.) I also can't reword my original commit message. So I guess I have to force push. But this makes it harder for collaborators to understand what has changed because GitHub garbage-collects old commits; sometimes I get the message that the old commit can't be found. On Gerrit, I (non-force) push to a "magic" ref which updates the PR for me.

3. As a code reviewer, it's really hard for me to understand what the PR author has changed since the last review. I think part of this is that by default GitHub shows the thread for a PR instead of the code. The thread view has a bunch of whitespace that makes it difficult to concisely understand what has changed. For an interface I use regularly, I really want a condensed view. Gerrit: https://chromium-review.googlesource.com/c/chromium/src/+/46...

4. Finally, Gerrit has a nice interface (like Critique) that concisely shows the PR history and what each individual is working on. (Here's a person picked randomly from Chromium code review: https://chromium-review.googlesource.com/q/owner:katzz@googl...). It's really useful for understanding what changes were made/are in progress. Again, GitHub's UI has so much whitespace that is definitely prettier but not useful for a tool that should help my productivity, not hurt it.

It doesn’t help with any of the other comments, but doesn’t GitHub let to customise the merge commit message, even when you squash-and-merge?

The company I work at has a merge queue bot that enforces that CI passes after every merge. Only the bot is allowed to merge main. So, not being able to customize the squashed message is also an issue with our tooling.

GitHub definitely does support (1)! You just comment and click “add to review” as you go and then submit them all together at the end. It’s been the default for a while now.

For (2) you definitely want Gerrit. For major improvements on (1), (3), and (4) you might like https://codeapprove.com which sits on top of GitHub and attempts to solve your pain points. Obviously I am biased!

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.

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.

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

I’m obviously biased but you might like 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!

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> [1]: <https://github.com/search?q=mirror%3Atrue&type=repositories>

Reply on news.ycombinator.com