Work studies / Teardown
How merge queues land parallel changes without breaking the main branch
When several changes are ready at once, how do you land them all without breaking what already works?
Two changes can each pass their tests and still break the main branch together. GitHub’s merge queue, bors and OpenStack’s Zuul solve this by testing changes in the order they’ll land. I’ll study how, then spend a week building a small queue for work done in parallel.
- Format
- Teardown
- What I’ll build
- A queue that takes several finished changes, tests each one on top of the ones ahead of it, and drops only the change that breaks things, not the whole batch.
- What I’ll reuse
- A landing queue for work split across several AI assistants at once, each owning its own files.
- Used by
- Bezl
- Status
- Planned · Dec 2026
What I’ll look at
How Zuul tests a change on top of the changes queued ahead of it before they’ve landed, and what happens when one in the middle fails. How bors batches changes and splits a failing batch to find the culprit. And how GitHub’s merge queue picks how many changes to test together.
My guess
I expect batching saves the most time when changes rarely clash, and costs the most when they often do. If each piece of work owns its own files and agrees on its interfaces first, clashes should be rare enough for large batches.
How I’ll prove it
I’ll replay a set of real changes through the queue, some made to clash on purpose, and compare how long it takes to land them one by one, in batches, and with testing ahead of time.
Whatever the timing, a broken change must never reach the main branch.