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!

There are competing effects at play here. While of course merging everything in to dmd would maximise one thing at the expense of others, that doesn’t have much bearing on whether merging any individual thing is worth doing. There is no slippery slope to fall down, just the usual balancing of factors based on insight from experience and theory.

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,

On Sunday, 12 February 2023 at 00:15:51 UTC, deadalnix wrote:
> Case in point: dustmite exists. While I certainly command Vladimir for his work,

I would rather he has spend his time and energy on something that provide value to the world rather than fixing limitation in the current toolchain.

On Sunday, 12 February 2023 at 00:18:35 UTC, deadalnix wrote:
> On Sunday, 12 February 2023 at 00:15:51 UTC, deadalnix wrote:
>> Case in point: dustmite exists. While I certainly command Vladimir for his work,
>
> I would rather he has spend his time and energy on something that provide value to the world rather than fixing limitation in the current toolchain.

I think you mean 'Digger'.
[https://github.com/CyberShadow/Digger]

On Sunday, 12 February 2023 at 00:49:04 UTC, Stefan Koch wrote:
> On Sunday, 12 February 2023 at 00:18:35 UTC, deadalnix wrote:
>> On Sunday, 12 February 2023 at 00:15:51 UTC, deadalnix wrote:
>>> Case in point: dustmite exists. While I certainly command Vladimir for his work,
>>
>> I would rather he has spend his time and energy on something that provide value to the world rather than fixing limitation in the current toolchain.
>
> I think you mean 'Digger'.
> [https://github.com/CyberShadow/Digger]

Yes, wow. This message got stuck due to a server outage, and I recovered it half written, and didn't do a great job at fixing it XD

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)?

I don't understand how this analogy applies unless you're advocating for a monorepo with all dub packages, which I doubt is the case.

> 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...

I don't think we can, because I'm asking about putting code that's under control by the same group of people in the same repository and I don't see how that applies to private individual projects.

On 14/02/2023 12:58 AM, Atila Neves wrote:
> 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)?
> 
> I don't understand how this analogy applies unless you're advocating for a monorepo with all dub packages, which I doubt is the case.

My point is that the arguments being made for it, are easily applied to other projects than just Phobos.

>> 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...
> 
> I don't think we can, because I'm asking about putting code that's under control by the same group of people in the same repository and I don't see how that applies to private individual projects.

It shouldn't be the same group!

Its a vastly different skill set to develop a compiler than it is to develop a standard library.

Same goes for things like GC's, it is its own specialty. We should be moving things out of dmd's repository, not moving them in!

On Tuesday, 14 February 2023 at 01:57:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Same goes for things like GC's, it is its own specialty. We should be moving things out of dmd's repository, not moving them in!

What practical problem would moving the GC out of the DMD repo solve?