Monorepo?

[deadalnix]

On Wednesday, 8 February 2023 at 00:40:44 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 07/02/2023 11:15 PM, Atila Neves wrote:
>> What special rule? If a dmd change breaks Phobos, doesn't it 
>> make more sense to fix Phobos in the same PR than submitting a 
>> separate PR to the Phobos repo (and having to explain that 
>> it's because of dmd PR #12345)?
>
> If a Phobos change breaks MIR, doesn't it make more sense to 
> fix MIR in the same PR than submitting a separate PR to the MIR 
> repo (and having to explain that its because of a Phobos PR 
> #12345)?
>
> We can apply this same logic to literally any code base that is 
> in the auto tester. The dmd repository is going to get quite 
> big when we keep including what should be isolated code bases 
> administratively...
>
> Personally I'm not sure that the zlib folks are going to want 
> to move development into the dmd repository. But hey, you guys 
> have pull so maybe you'll archive it!

It's interesting that you have all the elements to answer this 
dilemma yet do not see it.

The proliferation of repositories solve one problem, and one 
problem only: allow disparate organizations to collaborate 
without each other's processes, timeline, and whatnot disturbing 
the other too much. It creates an abstraction layer, which, while 
having a cost, remain beneficial because you'd have cross org 
friction instead, and it's much more costly.

When the different part fall under the same organization, you 
start paying that abstraction cost for no reason at all.

Case in point: dustmite exists. While I certainly command 
Vladimir for his work,