6 ms·

Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep trac

by csl 10y ago

Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep track of their different build statuses. Also, where I use it we have different levels of requirements for different branches (more people usually need to approve reviews on soon-to-be-released point branches). We use it for a large project in MLOCs but relatively few developers (less than a hundred). I can't see it would work for 4000 devs at all, though.

Too 10y ago
Could you elaborate why you think gerrit wouldn't work for 4000 devs? At that scale the project would be divided into smaller responsibility areas essentially operating on their own anyway.
- csl 10y ago
  Right, you could do that and probably do it well. I was mostly thinking about the simple matter of scaling the resources and maintenance crew to tackle 4000 devs. But my biggest concern about it is that it introduces centralization into the workflow. I do truly love Gerrit, but I get a bit worried about keeping a lot of important stuff in a centralized and not so transparent database.
adrianratnapala 10y ago
Perhaps I don't understand the Gerrit workflow, but last time I read about Gerrit it looked like it had a philosophy of "one commit, one review". That sounds like an anethema for the kernel, where they want to review a series of tidied up commits, one per email.
- kiallmacinnes 10y ago
  Gerrit does have "one commit, one review", but - that's not a bad thing. If a change is well written and structured, merging the first in the chain without the second+ is both harmless and is progress towards the end goal. There's also patch chains in Gerrit, so you can see the X commits that make up the full change, and the second+ cannot be merged before the first.
- xjia 10y ago
  Does the topic branch feature help? I personally always use it.
exDM69 10y ago
In my opinion, yes, Gerrit is awful. Perhaps my experience is made worse by the fact that our Gerrit servers (perhaps about 5000 users) are so painfully slow that it can take a minute to display a page. Multiply that by the number of files touched in a patch to get a whole review done. Then add all this non-vanilla Git extensions like "Change-Id" lines in commit messages and Gerrit/Repo's awkward idea of branches spanning multiple repositories. All this makes it difficult to deal with multiple patches that make a "feature", ie. a feature branch. Something that should be trivial in Git is made really difficult by Gerrit.
Confusion 10y ago
Our team of 10 thinks Gerrit is great. I don't know how these other people are using Gerrit, but I don't recognize their description at all. Gerrit is very convenient if you take code reviews seriously. I do agree that clicking through each file is a waste Well, firstly it is simply not true that you need to do that (you can accept/reject a review without having viewed any file at all), but secondly I'm totally fine with pressing ] 20 times for a review that touches 20 files. If the diff was a single unified diff, I'd have to press page-down a few times and those few keystrokes don't make much of a difference compared to the time taken to actually review code. Article says: Gerrit, he said, makes patch submission quite hard But without any explanation for why. It is hard to do local testing of patches in Gerrit, It's easy to checkout a review to its own branch, so why do they feel that way? All discussions are done through a web interface. Yeah, well, if using a web interface is a problem for you, then of course Gerrit is not a good tool for you. If you think the web interface doesn't add anything, then Gerrit is not a good tool for you. But those are not shortcomings of Gerrit, but simply a mismatch between your preferred workflow and your preferred way of interacting with code reviews.
- gurkendoktor 10y ago
  > Article says: > Gerrit, he said, makes patch submission quite hard > But without any explanation for why. You need to add hooks to inject a Change-Id into every commit, and be careful that they're still "fresh" (e.g. you cannot reuse one from an abandoned branch if you want to re-submit it). And you must push a diff to the server so it can be submitted to Gerrit. If your feature branch is up-to-date (you just force-pushed it), you cannot submit the same commit to Gerrit. And it gets worse when you have developers who rely on an IDE to get work done – the IntelliJ plugin for Gerrit is pretty buggy (I think it's okay for submitting now, but reviewing was still frustrating last month).
  - Confusion 10y ago
    If your feature branch is up-to-date (you just force- pushed it), you cannot submit the same commit to Gerrit. It sounds to me like this is where it's going wrong. If Gerrit is not also hosting your 'origin' git repositories and acting as a gatekeeper for any commit to be added to it, then you are working against the system. I don't see the problem with hooks and we rarely have problems with Change-Ids not being 'fresh' anymore (that sounds like the result of a suboptimal workflow). Bugs in plugins are of course not a good reason to say Gerrit isn't very good. That's like saying git itself sucked when the IntelliJ plugin for git still had annoying bugs.

by csl 10y ago

Too 10y ago

Could you elaborate why you think gerrit wouldn't work for 4000 devs? At that scale the project would be divided into smaller responsibility areas essentially operating on their own anyway.

csl 10y ago
Right, you could do that and probably do it well. I was mostly thinking about the simple matter of scaling the resources and maintenance crew to tackle 4000 devs. But my biggest concern about it is that it introduces centralization into the workflow. I do truly love Gerrit, but I get a bit worried about keeping a lot of important stuff in a centralized and not so transparent database.

adrianratnapala 10y ago

Perhaps I don't understand the Gerrit workflow, but last time I read about Gerrit it looked like it had a philosophy of "one commit, one review". That sounds like an anethema for the kernel, where they want to review a series of tidied up commits, one per email.

kiallmacinnes 10y ago
Gerrit does have "one commit, one review", but - that's not a bad thing. If a change is well written and structured, merging the first in the chain without the second+ is both harmless and is progress towards the end goal. There's also patch chains in Gerrit, so you can see the X commits that make up the full change, and the second+ cannot be merged before the first.
xjia 10y ago
Does the topic branch feature help? I personally always use it.

exDM69 10y ago

In my opinion, yes, Gerrit is awful. Perhaps my experience is made worse by the fact that our Gerrit servers (perhaps about 5000 users) are so painfully slow that it can take a minute to display a page. Multiply that by the number of files touched in a patch to get a whole review done. Then add all this non-vanilla Git extensions like "Change-Id" lines in commit messages and Gerrit/Repo's awkward idea of branches spanning multiple repositories. All this makes it difficult to deal with multiple patches that make a "feature", ie. a feature branch. Something that should be trivial in Git is made really difficult by Gerrit.

Confusion 10y ago

Our team of 10 thinks Gerrit is great. I don't know how these other people are using Gerrit, but I don't recognize their description at all. Gerrit is very convenient if you take code reviews seriously. I do agree that clicking through each file is a waste Well, firstly it is simply not true that you need to do that (you can accept/reject a review without having viewed any file at all), but secondly I'm totally fine with pressing ] 20 times for a review that touches 20 files. If the diff was a single unified diff, I'd have to press page-down a few times and those few keystrokes don't make much of a difference compared to the time taken to actually review code. Article says: Gerrit, he said, makes patch submission quite hard But without any explanation for why. It is hard to do local testing of patches in Gerrit, It's easy to checkout a review to its own branch, so why do they feel that way? All discussions are done through a web interface. Yeah, well, if using a web interface is a problem for you, then of course Gerrit is not a good tool for you. If you think the web interface doesn't add anything, then Gerrit is not a good tool for you. But those are not shortcomings of Gerrit, but simply a mismatch between your preferred workflow and your preferred way of interacting with code reviews.

gurkendoktor 10y ago
> Article says: > Gerrit, he said, makes patch submission quite hard > But without any explanation for why. You need to add hooks to inject a Change-Id into every commit, and be careful that they're still "fresh" (e.g. you cannot reuse one from an abandoned branch if you want to re-submit it). And you must push a diff to the server so it can be submitted to Gerrit. If your feature branch is up-to-date (you just force-pushed it), you cannot submit the same commit to Gerrit. And it gets worse when you have developers who rely on an IDE to get work done – the IntelliJ plugin for Gerrit is pretty buggy (I think it's okay for submitting now, but reviewing was still frustrating last month).
- Confusion 10y ago
  If your feature branch is up-to-date (you just force- pushed it), you cannot submit the same commit to Gerrit. It sounds to me like this is where it's going wrong. If Gerrit is not also hosting your 'origin' git repositories and acting as a gatekeeper for any commit to be added to it, then you are working against the system. I don't see the problem with hooks and we rarely have problems with Change-Ids not being 'fresh' anymore (that sounds like the result of a suboptimal workflow). Bugs in plugins are of course not a good reason to say Gerrit isn't very good. That's like saying git itself sucked when the IntelliJ plugin for git still had annoying bugs.