[llvm-dev] [RFC] One or many git repositories?

[Dean Michael Berris via llvm-dev]

> On 29 Jul 2016, at 22:47, Renato Golin <renato.golin at linaro.org> wrote:
> 
> On 29 July 2016 at 13:04, Dean Michael Berris via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Is it really impossible to just build non-LLVM dependent versions of libc++ or the sanitiser runtimes if they reside in one git megarepo?
> 
> The more intricate the relationship between the components, the less
> we'll test for the alternative solutions.
> 

I agree with this gem of an insight, thank you.

But that doesn't mean we wouldn't test for those -- just that we should be vigilant about it and do make sure we support the various use-cases we already do, and then some.

> My use is solely from a toolchain point of view. For me, having it all
> in one blob would be perfect, and I would never have to worry about
> integrations again. (in a perfect world, etc...)
> 
> But a good number of projects (and products) use LLVM trunk (not
> releases) and they use in slightly different ways. This has driven a
> lot of refactoring around the libraries over the last few years and I
> think it's a positive thing. A good number of *upstream* developers
> contribute to LLVM under those premises, and the harder we make for
> them, the less of them we'll have. I don't think that's a wise move.
> 

I don't see how making it a mono-repo would make it harder for them (LLVM developers) to keep things un-broken for this use-case *if* we have infrastructure already testing the standalone builds (which, AFAICT, we do, because I've broken them a couple of times now :D). Note this is predicated on making sure we do have explicit tests for these situations and I 100% agree that we should have those.

But that is beside the point of whether we have a mega-repo or 100 different smaller ones. (I exaggerate, we only have ~10 or so, I've already lost count). In fact I think having the many "independent" repositories makes it harder to test (as is already the case).

> Furthermore, losing the ability to clearly separate things makes them
> become one disparate group, rather than two independent ones.
> 

Can you elaborate more on why keeping things separate is beneficial to:

- Current and future LLVM vertical developers (those working on LLVM, Clang, compiler-rt, parallel_libs, etc.)
- Downstream users who have to keep track of the separate projects and repositories in their local workflows
- Casual contributors who find bugs and want to help clean something up

From someone who's new to all this LLVM development, I'd really like to understand why it _seems_ like we really want to keep the status quo of "too hard to make changes and maintain". I understand the "engineering tradeoff" between not changing something that's already working, but there's also the principle of "continuous improvement" -- i.e. if a megarepo makes the development process simpler and enables us to support *more* downstream users *better*, maybe that's a strictly better situation than what we have now?

Cheers