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 ...
@xahteiwi Any recommendations on the most painless way to host Zuul? Do you have a Heat template or whatever the modern equivalent is these days?

@aspiers I don't think there is a painless way to host Zuul.

Quod licet OpenStacki, non licet random shmucki.

(And all of us with projects of <1000 developers are random shmucks, in this context.)

@xahteiwi I asked for "the most painless way", not an *entirely* painless way ;-)
@aspiers Okay what would be your preferred anaesthetic/analgesic?
@xahteiwi My preference is to ask smart experts who have already been through the pain ๐Ÿ˜œ But if your conclusion is "it's not worth it, use GitLab" and mine was "please god anything but GitLab or GitHub", then it might be really interesting to get together to compare the pros and cons at some point... or should I say, cons and cons ๐Ÿคฆโ€โ™‚๏ธ ๐Ÿ˜†

@aspiers The problem I have with Gerrit/Zuul is that for everything it does really well and better than GitHub and GitLab, there seem to be two things that it doesn't do worse, but that it does not all โ€” leaving it to you to implement comparatively trivial CI features yourself.

Here's one such example:

https://mastodon.social/@xahteiwi/109745631666197230

@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