From: rra@debian.org
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 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 (rra@debian.org)
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
