guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Contribute or create a channel?


From: Attila Lendvai
Subject: Re: Contribute or create a channel?
Date: Tue, 12 Mar 2024 13:18:21 +0000

> > the patch inflow to the guix repo is currently overwhelming the
> > available capacity for review and pushing.
> 
> 
> With an email like the one sent by Hartmut we can better arrange for
> shepherding this large submission. (Nothing is to be gained from
> repeatedly bemoaning well-known issues in the patch review processes
> here and in other threads on the mailing list.)


i was reflecting on why i wrote this, and what i wanted to express is that i 
think guix has reached a point where a monorepo is becoming a net negative, and 
i don't see this being discussed.

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.

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

or alternatively, simply try to split guix into a minimal core that is 
essential for the bootstrap, and everything else into multiple subchannels 
(gnome, gui stuff in general, random apps, etc). i have no impression how much 
that alone could shrink the monorepo part, though.

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.

sadly, i don't have any proposals beyond discussing the observable issue (i.e. 
the insufficient patch throughput).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Values in a free society are accepted voluntarily, not through coercion, and 
certainly not by law… every time we write a law to control private behavior, we 
imply that somebody has to arrive with a gun [to enforce it].”
        — Ron Paul




reply via email to

[Prev in Thread] Current Thread [Next in Thread]