This is entirely an aside, so folks following the rest of the thread can ignore it. I decided to go ahead and send it to debian-devel since it's the sort of general technical discussion that I personally enjoy reading here, although apologies if folks consider it noise since it's not really something Debian can act on.
Jeremy Stanley <fu...@yuggoth.org> writes: > On 2025-08-15 18:53:38 -0700 (-0700), Russ Allbery wrote: >>a Gerrit instance that probably doesn't exist any more > [...] > If you're referring to gerrit.openafs.org, it's still up and running. Ah! I should have checked first. I'm glad to hear that! > As an aside, I really wish the GitHub/GitLab generation could experience > and appreciate how superior of a code review platform Gerrit really is > (not as much the one for OpenAFS because it's not been upgraded in close > to a decade, but more generally). Not going to turn this into a > religious debate though... I too am someone who really liked Gerrit better than a lot of the things that came later. That said, GitHub at least has gotten a lot better over the years. In particular, they added incremental reviews (only showing you the bits that have changed since your previous review), commit-by-commit review (or maybe that's always been there and I just figured out how to find it), and merge queues, which get pretty close to the UI experience that I liked with Gerrit. It looks like GitLab supports their own concept of merge queues (which they call merge trains). I am woefully behind in adopting Salsa CI because I really need to sit down and spend a day mapping my understanding of GitHub to GitLab and haven't been able to find the day, but I would look at using merge trains for Debian packaging since the semantics are fantastic for fire and forget changes to a bunch of packages. You can just make an MR and enable automerge, and not only will you be told if the merge didn't happen because some test failed, your change will also be serialized with any work someone else is doing at the same time and will only be merged if it's safe (no conflicts and tests pass). We only use merge queues for one repository at work, but it's a lifesaver for that one since it gets probably 20-40 merges a day and often there are multiple things going on at the same time. It's great to not have to babysit a merge request to get it merged. I'm not sure off-hand if GitLab also has incremental and commit-by-commit review (I would know this if I did more GitLab reviewing, but I haven't done that in quite a while, again just due to lack of time). One feature I do still miss from Gerrit that I don't think GitHub has is the ability to merge a single commit from a merge request composed of multiple commits. With GitHub, so far as I know, I have to manually add the remote locally and cherry-pick the commit, which is kind of annoying. With Gerrit, the commits were separated, which had its pluses and minuses but which made partial merges easy. That way you can merge the bits of a multi-commit change that are uncontroversial and then iterate on the remaining changes. I don't know if GitLab has something better here. I do like that GitHub and GitLab let you choose which bits and pieces you want to use and you can use them like a pure dumb Git server if you want to. That provides some nice flexibility when different projects warrant different levels of review. You can use branch protection rules to enforce the level of review that you want. Gerrit, at least from 15 years ago, really wanted to take over your entire repository and force everything through its idea of reviews, and while it was possible to bypass Gerrit, it wasn't as cleanly incremental as GitHub allows. Maybe that's subsequently changed (or maybe I misunderstood Gerrit originally; that's entirely possible). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
