Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The origin story of merge queues

mergify.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: The origin story of merge queues

#11

Post by wbl »

jd__ wrote: post #6
zdw wrote: post #3

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…

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…

Gerrit integrates with try and mergebots I thought.

Re: The origin story of merge queues

#12

Post by jd__ »

Roguelazer wrote: post #8

I think this is ignoring a lot of prior art. Our deploys at Yelp in roughly 2010 worked this way -- you flagged a branch as ready to land, a system (`pushmaster` aka `pushhamster`) verified that it passed tests and then did an octopus merge of a bunch of branches, verified that that passed tests, deployed it, and then landed the whole thing to master after it was happy on staging. And this wasn't novel at Yelp; we in…

That's super interesting, thanks for sharing the Yelp/PayPal lineage. You're right: there's probably a lot of prior art in internal release engineering systems that never got much written up publicly.

The angle we took in the blog post focused on what was widely documented and accessible to the community (open-source tools like Bors, Homu, Bulldozer, Zuul, etc.), because those left a public footprint that other teams could adopt or build on.

It's a great reminder that many companies were solving the "keep main green" problem in parallel (some with pretty sophisticated tooling), even if it didn't make it into OSS or blog posts at the time.

Re: The origin story of merge queues

#13

Post by qlm »

jd__ wrote: post #12
Roguelazer wrote: post #8

I think this is ignoring a lot of prior art. Our deploys at Yelp in roughly 2010 worked this way -- you flagged a branch as ready to land, a system (`pushmaster` aka `pushhamster`) verified that it passed tests and then did an octopus merge of a bunch of branches, verified that that passed tests, deployed it, and then landed the whole thing to master after it was happy on staging. And this wasn't novel at Yelp; we in…

That's super interesting, thanks for sharing the Yelp/PayPal lineage. You're right: there's probably a lot of prior art in internal release engineering systems that never got much written up publicly. The angle we took in the blog post focused on what was widely documented and accessible to the community (open-source tools like Bors, Homu, Bulldozer, Zuul, etc.), because those left a public footprint that other teams…

Gotta be honest: the AI-ness of both the images and the text in this blog post (as well as your response) leaves a bad taste.

Re: The origin story of merge queues

#14

Post by masklinn »

myelin wrote: post #4

The Chromium commit queue slightly predates this -- they started using it in 2010.

while the article does not provide specific dates for the “prehistory” the Not Rocket Science piece refers to an automated integration system working circa 2000~2001:

> February 2 2014, 22:25 […] Thirteen years ago I worked at Cygnus/RedHat […] Ben, Frank, and possibly a few other folks on the team cooked up a system [with a] simple job: automatically maintain a repository of code that always passes all the tests.

Re: The origin story of merge queues

#17

Post by [deleted] »

jd__ wrote: post #6
zdw wrote: post #3

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…

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…

[deleted]

Re: The origin story of merge queues

#18

Post by kccqzy »

> The motivation was to avoid "merge skew," where changes appear compatible when reviewed in isolation but break once merged into an updated main.

My opinion is that this situation of a merge skew happens rarely enough not to be a major problem. And personally, I think instead of the merge queues described in the article, it would be overall more beneficial to invest in tooling to automatically revert broken commits in your main branch. Merging the PR into a temporary branch and running tests is a good thing, but it is overly strict to require your main branch to be fast forwarded. You can generally set a time limit of one day or so: as long as tests pass when merging the PR onto a main branch less than one day old, you can just merge it.

Re: The origin story of merge queues

#20

Post by [deleted] »

Roguelazer wrote: post #8

I think this is ignoring a lot of prior art. Our deploys at Yelp in roughly 2010 worked this way -- you flagged a branch as ready to land, a system (`pushmaster` aka `pushhamster`) verified that it passed tests and then did an octopus merge of a bunch of branches, verified that that passed tests, deployed it, and then landed the whole thing to master after it was happy on staging. And this wasn't novel at Yelp; we in…

[deleted]
Post reply on HN