3 ms·

Do you really feel that confident working in another team’s code base? I work in a multi-repo company, and almost every time I’ve gotten a patch from outside my

Do you really feel that confident working in another team’s code base? I work in a multi-repo company, and almost every time I’ve gotten a patch from outside my team it’s been wrong in some way. Why would I want to make it easier for people who don’t understand (and aren’t interested in understanding) my project to land code in it?

z0r 5y ago
Because any company reaching monorepo scale will have integration tests that cut across the boundaries of your projects. It's possible for an outside contribution to break your corner of the repo, but the flip side is that you will know much more quickly if your own changes break another part of the repo.
- majormajor 5y ago
  >Because any company reaching monorepo scale will have integration tests that cut across the boundaries of your projects. Heh. This makes a couple assumptions that I only can wish were true: (a) that people won't go to monorepo until they hit some huge scale, and (b) that people will at that point have good test coverage.
- thelopa 5y ago
  I completely disagree. My company is absolutely “monorepo scale”, but I also know we’re nowhere close to having the test coverage to allow people unfamiliar with a project to freely land changes in it.
tylerhou 5y ago
Another advantage of a mono-repo is that it encourages everyone to use the same tooling & coding libraries. So (at least at Google) I can open another team's codebase (as long as it's in the main mono-repo) and understand it within ~10 minutes. I fix bugs that bother me in random projects (both internal and external) maybe once a month (most recently, in the large scale change tool!). For context, I've been at Google for ~3 years. I've only had a changelist rejected once, and that was because the maintainer disagreed with the technical direction of the change and not the change itself.
skybrian 5y ago
I think you’re misunderstanding something because this isn’t (usually) a way to bypass code review by the team that owns the code. You want to make it easier to contribute so that people can send a patch and it’s more likely to be useful without too much back-and-forth in code review. Having common tools and coding standards makes that more likely.

z0r 5y ago

Because any company reaching monorepo scale will have integration tests that cut across the boundaries of your projects. It's possible for an outside contribution to break your corner of the repo, but the flip side is that you will know much more quickly if your own changes break another part of the repo.

majormajor 5y ago
>Because any company reaching monorepo scale will have integration tests that cut across the boundaries of your projects. Heh. This makes a couple assumptions that I only can wish were true: (a) that people won't go to monorepo until they hit some huge scale, and (b) that people will at that point have good test coverage.
thelopa 5y ago
I completely disagree. My company is absolutely “monorepo scale”, but I also know we’re nowhere close to having the test coverage to allow people unfamiliar with a project to freely land changes in it.

tylerhou 5y ago

Another advantage of a mono-repo is that it encourages everyone to use the same tooling & coding libraries. So (at least at Google) I can open another team's codebase (as long as it's in the main mono-repo) and understand it within ~10 minutes. I fix bugs that bother me in random projects (both internal and external) maybe once a month (most recently, in the large scale change tool!). For context, I've been at Google for ~3 years. I've only had a changelist rejected once, and that was because the maintainer disagreed with the technical direction of the change and not the change itself.

skybrian 5y ago

I think you’re misunderstanding something because this isn’t (usually) a way to bypass code review by the team that owns the code. You want to make it easier to contribute so that people can send a patch and it’s more likely to be useful without too much back-and-forth in code review. Having common tools and coding standards makes that more likely.