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

21–30 of 63 posts

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

#21

Post by sroussey »

inigyou wrote: post #13
kyrra wrote: post #8

Earlier quoted context omitted.

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…

It should be sharded per team. I think many shops made the mistake of sharding per deployment unit or compilation unit of a larger whole. My first exposure was sharding per executable file of a firmware image. That's just terrible. You can't coordinate changes that you want to be atomic in the firmware image. In response I think some people went to monorepo to get atomic change sets but now they're too big. If you ha…

No, team is way too small. Team group is a better resolution. You want a certain amount of ownership for a repo that will survive a team being laid off, for example. And a bit of cross responsibility may seem annoying to a single IC, but is beneficial to the company.

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

#22

Post by fragmede »

kyrra wrote: post #17
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…

The problem with many of these tools is they are built on lots of other tech, like S3 dev called out: https://x.com/haipingfu/status/2084880266858995990 Piper is built on lots of other tech like spanner and chubby and many others. And some of those have specific hardware requirements that only exist in Google datacenters. Untangling that web of tech is neigh impossible (or not something worth the cost to leadership).

Why is that a problem? They sell Spanner on GCP. Sell Piper as well! It's obvious as shit but Google doesn't know what it's doing anymore. They should have bought GitHub, not Microsoft, and then we wouldn't have had the problems with scaling GitHub either.

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

#23

Post by inigyou »

sroussey wrote: post #21
inigyou wrote: post #13

Earlier quoted context omitted.

It should be sharded per team. I think many shops made the mistake of sharding per deployment unit or compilation unit of a larger whole. My first exposure was sharding per executable file of a firmware image. That's just terrible. You can't coordinate changes that you want to be atomic in the firmware image. In response I think some people went to monorepo to get atomic change sets but now they're too big. If you ha…

No, team is way too small. Team group is a better resolution. You want a certain amount of ownership for a repo that will survive a team being laid off, for example. And a bit of cross responsibility may seem annoying to a single IC, but is beneficial to the company.

I use the word team loosely as people who work together, not people under a single direct manager. Thanks for the clarification.

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

#24

Post by consensus1 »

jedberg wrote: post #18

I believe that the solution to the coordination problem is good monorepo tooling (like the OP) plus AI to understand the whole codebase and help the engineers understand how their part fits in. I was one of the biggest proponents of microservices, going so far as to traveling around the world spreading the gospel of microservices keynoting large tech conferences. I believed that microservices were the best solution t…

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

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

#25

Post by akshayshah »

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.

Huh - are you sure? I was pretty sure that the original implementation came from the Android & iOS repos.

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

#26

Post by twic »

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.

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

#27

Post by sdfhbdf »

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 enterprise server installation) that does the same thing:

> When a pull request is added to the merge queue, the changes in the pull request are grouped into a merge_group with the latest version of the base_branch as well as changes from pull requests ahead of it in the queue. GitHub will merge all these changes into the base_branch once the checks required by the branch protections of base_branch pass.

https://docs.github.com/en/repositories/configuring-branches...

I understand not everybody uses GitHub but I'm pretty sure other providers also have similar features, e.g. https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-m...

So what's different/special about Uber's thing?

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

#28

Post by mupuff1234 »

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…

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.

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

#29

Post by fastball »

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.

Do you do any cross workspace/repo work, or are you mostly constrained to a single namespace?

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

#30

Post by yissachar »

jedberg wrote: post #18

I believe that the solution to the coordination problem is good monorepo tooling (like the OP) plus AI to understand the whole codebase and help the engineers understand how their part fits in. I was one of the biggest proponents of microservices, going so far as to traveling around the world spreading the gospel of microservices keynoting large tech conferences. I believed that microservices were the best solution t…

You can have microservices while still using a monorepo. They are still useful for creating service topology that can segment scaling and permissions, though I think people get carried away in the number of services created.

I think the eventual sweet spot will be monorepos that have good modular boundaries, and dynamically adjusting service topology that doesn't rely on pre-committed decisions on what code lives in a "service".

Post reply on HN