Hi Attila,

I know this wasn't directly sent to me, but I wanted to share a couple
of thoughts anyway :-)

On 2024-03-12 14:18, Attila Lendvai wrote:
> my gut feeling is that new abstractions are needed that would enable splitting the monorepo/community into less tightly coupled subgroups where they can have their own coding standards, repos, channels, etc, and a more federated way to maintain/integrate all the software that exists out there into a guix system.

As an end user, it is incredibly nice to have a single Guix channel to
pull from.  I just have to remember (or write down...) a single commit
hash and that's all that's required to reproduce my setup.

> channels are a step towards this, but they are not enough in their current form to successfully accommodate for such a setup. an obvious thing that is missing is a way to formally express inter-channel dependencies, including some form of versioning.

Although I understand where you are coming from, I am not convinced that
this solves more problems than it causes.  For example, a naive approach
to inter-channel dependencies with versioning could reintroduce the
diamond dependency problem.  However, solving this by locking every
single transitive dependent channel would not allow security updates
across all of them simultaneously anymore.

> in this hypothetical setup commit rights could be issued much more liberally to non-core sub-repos, and more rigorous code reviews would only need to be done when a new version of the split-out part is being incorporated back into a new revision of the core/bootstrap chain (if e.g. assuming python is needed for the bootstrap of the core, then the python subgroup's stuff would only need core review when a new version of that is pointed to by the core).

The same topic has come up in Nix as well [1, 2, 3], but they are using
Github, so they are bound to a centralized workflow.  Using Github (or
any such git forge for that matter) reintroduces some of the same
problems Git was designed to solve in the first place, which become most
painful at scale [4].

From a technical point of view, I don't see why we couldn't split into
less tightly coupled subgroups with their own repos, standards and CI
merging into a single Guix "monorepo".  I think there is still a lot to
learn from how the kernel does its development and we could extrapolate
to something that makes sense for Guix.

Best wishes,

Troy

[1]
https://discourse.nixos.org/t/wild-idea-how-about-splitting-nixpkgs-and-nixos/11487/25
[2] https://github.com/NixOS/rfcs/pull/70
[3] https://github.com/NixOS/nixpkgs/issues/50105
[4] https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html