News for hackers. Stuff that matters.
Re:The Origin Story of Merge Queues by zdw on Wednesday September 10, 2025 @12:49PM (#45200423)
This seems to skip the idea of stacked commits plus automatic rebasing, which have been around in Gerrit and other tools for quite a while.

If you read between the lines, the underlying problem in most of the discussion is GitHub's dominance of the code hosting space coupled with it's less than ideal CI integration - which while getting better is stuck with baggage from all their past missteps and general API frailty.

Re:The Origin Story of Merge Queues by jd__ on Wednesday September 10, 2025 @01:01PM (#45200599)
That's a good point. To clarify, Gerrit itself didn't actually do merge queuing or CI gating. Its model was stacked commits: every change was rebased on top of the current tip of main before landing. That ensured a linear history but didn't solve the "Is the whole pipeline still green when we merge this?" problem.

That's why the OpenStack community built Zuul on top of Gerrit: it added a real gating system that could speculatively test multiple commits in a queue and only merge them if CI passed together. In other words, Zuul was Gerrit's version of a merge queue.

Re:The Origin Story of Merge Queues by wbl on Wednesday September 10, 2025 @01:36PM (#45201077)
Gerrit integrates with try and mergebots I thought.