Re: Is Guix suitable for large monorepos?

[Liliana Marie Prikler]

Am Freitag, dem 22.07.2022 um 11:14 +0200 schrieb Maxime Devos:
> On 22-07-2022 08:58, Liliana Marie Prikler wrote:
> 
> > 15:10 "An engineering organization is not a bottom-up kind of
> > thing"
> > (X) Doubt.
> > 15:18 "In a well functioning engineering team, priorities and
> > decisions
> > and effort allocation flow top-down"
> > (X) Doubt.
> > 15:24 "Some sort of top-down organization is required"
> > (X) Doubt.
> 
> It's a bit of a stretch, but in a sense Guix is a bit top down, if
> you count Guix itself (and the reviewers, committeres, etc. as a
> while) as 'top' and individual patch submitters as 'down'.  OTOH with
> Guix doesn't make decisions on what individual people should work on,
> only on the rules that the results should follow and there is no
> effort allocation, so possibly this is not the kind of 'top-down'
> that the video was referring to.
To expand on this a little, there are about two important layers here:
committers and non-committers.  Within the review process both are the
same, except for the fact that only committers can actually push
changes to the repo (signing with their name and key).  Also, thanks to
channels, packages can really flow from the bottom up – someone who
wants to submit a package can first check it locally, and even while
the review is ongoing already use it on their machine.  Now there are
maintainers, who are even more powerful than committers and recently
also teams, but for better or worse neither of those matter too much in
your day to day operations.

In the context of the monorepo debate, I think it is also important to
distinguish between Guix, the package manager, and Guix, the channel. 
Governance decisions regarding the latter can largely be ignored if
you're working for MonoRepoCorp™.

Cheers