Dear lazyweb, I have a GitHub (mono)repo with a bunch of CI implemented as GitHub Actions. I want to move away from GitHub's godawful PR review design towards a sensible system which enforces one commit per review cycle, e.g. all the goodness of Gerrit plus Zuul for CI and policy-based merges, but without having to rewrite CI from scratch or lose branch protection. Is this easily doable? Tools like spr and ghstack for stacking 1-commit PRs only solve part of the problem.
And when I wrote "Dear lazyweb", I really meant "Dear @xahteiwi or any Zuul guys who are hiding on here" ...

@aspiers Did you really just ask if something was "easily doable"... in Zuul?

I have found next to nothing to be "easily doable" in Zuul.

@xahteiwi I can live with difficult setup as long as it's a one-time thing - the rewards of getting away from hideous GitHub code review can justify a huge up-front cost ...

@aspiers What is it, specifically, that Gerrit/Zuul does better than GitLab with merge trains?

(This is not a rhetorical question. You want to enumerate what advantages the Gerrit/Zuul combo has over both GitHub and GitLab in review and CI quality, and then weigh that against the suction it comes with in UX and having to build even trivial CI features yourself.)

@xahteiwi Regarding the former, I did partially enumerate that, as you probably remember: https://bit.ly/code-review-comparison

However I have a lot more to say on that topic, and in particular how GitHub's/GitLab's design decision of allowing multiple commits per review cycle has a profoundly negative impact on code quality and team efficiency.

Regarding the latter (the downsides of Gerrit/Zuul setup), that was basically the point of my original question.

GitHub vs. Gerrit vs. GitLab

github-gerrit Rosetta stone translating workflows between GitHub / Gerrit / GitLab GitHub,GitLab,OpenStack Gerrit (review.opendev.org) Concepts / design Name for a change uploaded for review,Pull request (a.k.a. PR),Merge request (a.k.a. MR),Review Number of commits allowed in a review,Any (non-...

Google Docs

@xahteiwi BTW I did substantial research before concluding that this is currently nowhere near solved or even solvable in GitLab, e.g. https://gitlab.com/gitlab-org/gitlab/-/issues/11393#note_1014000534

I could easily do a 90 minute talk on this whole topic. Luckily I don't have the time for that ;-)

Complex merge order dependencies (#11393) 路 Issues 路 GitLab.org / GitLab 路 GitLab

Problem to solve In https://gitlab.com/gitlab-org/gitlab-ee/issues/9688 , we're adding the first iteration of merge ordering - this forms a directed acyclical...

GitLab