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

Uber SubmitQueue: a high-performance speculative merge queue

github.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Uber SubmitQueue: a high-performance speculative merge queue

#41

Post by IshKebab »

sdfhbdf wrote: post #27

I'm reading from the repo and I'm a little dumbfounded what's the innovation. > SubmitQueue speculatively rebases and validates multiple changes in parallel against predicted future states of HEAD. When validations pass, changes land automatically. When they fail, SubmitQueue isolates the offending change and retries the rest — all without human intervention. This seems to be a feature of GitHub (We have it in an old…

I think it's much cleverer about the order in which it tries to merge PRs, and how they are grouped.

GitHub merge queues just do it in the order you click.

Also I'm pretty sure it predates GitHub's implementation by a fair bit. Uber were one of the first people to do this. Maybe the first IIRC.

Re: Uber SubmitQueue: a high-performance speculative merge queue

#42

Post by plumeria »

fcarraldo wrote: post #31
mupuff1234 wrote: post #28

Earlier quoted context omitted.

I don't understand how come monorepos never just got "solved", and why git didn't expand in that direction. I switched from a company with a monorepo to one without, and it just feels like going back to the stone age.

I work at a monorepo company and any time someone gets to work on a project that necessitates working outside of the monorepo, it's a night-and-day improvement. Tools, especially open source ones (linters, static analysis, scanning, LSPs, IDEs, etc) are not built for monorepos, and with AI Agents working in the monorepo results in an enormous increase in input tokens as the agents are constantly trying to grep this g…

> Tools, especially open source ones (linters, static analysis, scanning, LSPs, IDEs, etc) are not built for monorepos, and with AI Agents working in the monorepo results in an enormous increase in input tokens as the agents are constantly trying to grep this giant source tree.

I've been thinking that one could dynamically patch .claude/settings.json (or its equivalent for other agents) to allow reads/writes only to the active app/package being edited and its dependencies (other packages/apps).

Re: Uber SubmitQueue: a high-performance speculative merge queue

#43

Post by mi_lk »

kyrra wrote: post #8
mi_lk wrote: post #4

Monorepo benefits maybe a small set of developers that manages it for the whole company, at the cost of most other engineers who develop in it. Unnecessary waste of time. Case in point another new merge queue has to be created to somehow manage the messiness

It's really the case that Git is terrible at scale. Honestly most source control is. When you have teams of 10,000+ people working on code, if you wanted to shard it, it will be lots of little projects, then you're going to have dependency hell. The core in for teams will either have to spend most of their time upgrading everyone's packages, our other teams are going to have to deal with those upgrades. The core infr…

That doesn't counter my point - yes there'll be dependency hell but at the same time fundamental developer tools like code intelligence or basic git operations take eons to complete or need strange workarounds

So code infra/library team benefit from monorepos but at the same time most other developers have to suffer

I don't know about Google but monorepos I've worked in are painful and far from ideal dev experience

Re: Uber SubmitQueue: a high-performance speculative merge queue

#44

Post by para_parolu »

sdfhbdf wrote: post #27

I'm reading from the repo and I'm a little dumbfounded what's the innovation. > SubmitQueue speculatively rebases and validates multiple changes in parallel against predicted future states of HEAD. When validations pass, changes land automatically. When they fail, SubmitQueue isolates the offending change and retries the rest — all without human intervention. This seems to be a feature of GitHub (We have it in an old…

I was long before github made it. Otherwise thing is similar from usage perspective

Re: Uber SubmitQueue: a high-performance speculative merge queue

#45

Post by wbxp99 »

medellin wrote: post #19

The origin of this was from Uber ATC self driving division. We wrote the original submit queue inside of Phabricator and then it was eventually pulled out and made its own product. It was fun to work on and find all the edge cases along the way.

For those wondering “why is this needed”, IIRC the build took ~6 hours, so batching builds and testing were necessary to keep up

Re: Uber SubmitQueue: a high-performance speculative merge queue

#46

Post by claytonjy »

jedberg wrote: post #36
mnahkies wrote: post #34

Earlier quoted context omitted.

I'm going to play devil's advocate here. As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down). As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness…

> The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time. Which is why m…

if service A calls service B, and service B adds a new endpoint, or a new optional argument, service A needs an update to take advantage of it

if a library is used by multiple services, and gets an important bug fix, each service using the library needs to update to get the fix

these are sequences of changes, not literally at the same time or requiring deployment coordination, but when this happens a lot people start asking about monorepos

Re: Uber SubmitQueue: a high-performance speculative merge queue

#47

Post by IshKebab »

twic wrote: post #26
esprehn wrote: post #7

Airbnb has a version of this internally that was pretty awesome called Evergreen, based on the Uber paper as well. I wish more companies would open source their monorepo infra. A well done monorepo is a huge force multiplier on a large organization, but the OSS world is lacking a lot of the infra so everyone starts from a painful place and works up or has a bad impression of monorepos. Google's Piper is another examp…

> A well done monorepo is a huge force multiplier on a large organization How so? I work at a company which uses a monorepo, and I haven't seen any upside to it yet. We have a tools team that's invested a vast amount of work in it. Still seems strictly worse than a 'normal' polyrepo setup. I haven't understood why so many people are so enthusiastic about it.

1. No submodules. They suck. They don't work with worktrees. They're a pain to work with.

2. Cross-project changes become trivial instead of nightmarish.

3. Testing becomes tractable. Make a change in a submodule? Good luck testing that it doesn't break any of the other repos that depend on it. You essentially turn its API into a fully public API, which introduces a ton of extra work (if you do it right, which nobody does).

Re: Uber SubmitQueue: a high-performance speculative merge queue

#48

Post by claytonjy »

jedberg wrote: post #32
consensus1 wrote: post #24

Earlier quoted context omitted.

Microservices is a deployment strategy. Monorepo is a code organization strategy. They are not mutually exclusive.

While you are technically correct (the best kind of correct), I would challenge you to find an organization that is doing the monorepo/microservice combo correctly. And what I mean by that is with microservices, the API is the only contract. Every service should be deployable independently. If you have a monorepo, you're almost certainly violating that somewhere, using a shared library, or a shared database, or even…

[dead]

Re: Uber SubmitQueue: a high-performance speculative merge queue

#49

Post by fcarraldo »

plumeria wrote: post #42
fcarraldo wrote: post #31

Earlier quoted context omitted.

I work at a monorepo company and any time someone gets to work on a project that necessitates working outside of the monorepo, it's a night-and-day improvement. Tools, especially open source ones (linters, static analysis, scanning, LSPs, IDEs, etc) are not built for monorepos, and with AI Agents working in the monorepo results in an enormous increase in input tokens as the agents are constantly trying to grep this g…

> Tools, especially open source ones (linters, static analysis, scanning, LSPs, IDEs, etc) are not built for monorepos, and with AI Agents working in the monorepo results in an enormous increase in input tokens as the agents are constantly trying to grep this giant source tree. I've been thinking that one could dynamically patch .claude/settings.json (or its equivalent for other agents) to allow reads/writes only to…

You can, if you have a trusted build graph. I know that “cone-shaped” checkout tools like this are common in monorepo environments, but unfortunately there aren’t any maintained open source implementations that I’m aware of.

Re: Uber SubmitQueue: a high-performance speculative merge queue

#50

Post by jedberg »

claytonjy wrote: post #46
jedberg wrote: post #36

Earlier quoted context omitted.

> The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time. Which is why m…

if service A calls service B, and service B adds a new endpoint, or a new optional argument, service A needs an update to take advantage of it if a library is used by multiple services, and gets an important bug fix, each service using the library needs to update to get the fix these are sequences of changes, not literally at the same time or requiring deployment coordination, but when this happens a lot people start…

But a monorepo wouldn't make any of that easier.

You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo.

A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.

Post reply on HN