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
OpenPGP_0xC67C9181B3893FB0.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
