unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>
To: Maxime Devos <maximedevos@telenet.be>, jgart <jgart@dismail.de>,
	Guix Devel <guix-devel@gnu.org>
Subject: Re: Is Guix suitable for large monorepos?
Date: Fri, 22 Jul 2022 11:26:37 +0200	[thread overview]
Message-ID: <190111b666fbb3ffc8b4f9025c99313267c5e3ba.camel@ist.tugraz.at> (raw)
In-Reply-To: <d25f610d-b766-9665-ed1f-d8c3424a69bb@telenet.be>

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


  reply	other threads:[~2022-07-22  9:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-22  4:55 Is Guix suitable for large monorepos? jgart
2022-07-22  6:07 ` Ryan Sundberg
2022-07-22  6:58 ` Liliana Marie Prikler
2022-07-22  9:10   ` Maxime Devos
2022-07-22  9:14   ` Maxime Devos
2022-07-22  9:26     ` Liliana Marie Prikler [this message]
2022-07-22 14:25 ` Katherine Cox-Buday
2022-07-28 21:39   ` Blake Shaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=190111b666fbb3ffc8b4f9025c99313267c5e3ba.camel@ist.tugraz.at \
    --to=liliana.prikler@ist.tugraz.at \
    --cc=guix-devel@gnu.org \
    --cc=jgart@dismail.de \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).