[bug#61894] [PATCH RFC] Team approval for patches

[Simon Tournier]

Hi Andreas,

Re-reading the thread, I think we started with different frames. :-)


On ven., 10 mars 2023 at 15:19, Andreas Enge <andreas@enge.fr> wrote:

> while I am sensitive to your argument about privileges, I am afraid that
> the suggestion would remove privileges from the committers, while not
> bestowing them on anybody else; as a result, everybody would be worse off
> than before. Right now one out of the (let us be pessimistic) 20 active
> committers can push any patch from the issue tracker, say for a package
> trivially obtained via "guix import pypi ...". With the suggested change,
> the currently 1 (and in future hopefully one out of a few) members of the
> python group will have to approve the patch. In that situation, there is
> no incentive for anybody else to even look at the patch (without agency,
> why would one bother?), and we will effectively have split the Guix project
> into a collection of walled gardens.

What you are pointing is that not all the teams are willing to
collaborate the same way.  For sure I agree that updating a leaf package
does not require any more extra work – processing the submission by the
committer is already enough boring work.

However, for some packages or changes, the impact is far from being
trivial.  I have in mind many changes that happen aside gnu/packages and
also some core packages (Guile, etc.).

For these kind of changes, it does not appear to me so crazy to ask more
than the submitter or committer eyes.  For instance, one can read from
recent messages,

        this "trivial" patch implies a Julia (almost) world rebuild --
        so potentially some breakages.  And personally, I cannot run
        again and again after broken packages from unrelated
        changes. :-)

or

        To be clear, it’s time-consuming and stressful.  That’s not sane and I’d
        rather not work that way.

https://yhetil.org/guix/CAJ3okZ3j+HTATsoGE978b+LGk0KAEM7-BAGSy_Gtm61FzTWwQA@mail.gmail.com
https://yhetil.org/guix/87cz5qyv10.fsf@gnu.org

The wording of the patch is misleading but, I guess, the intent is to
smooth these kind of situations.

For sure, QA is helping a lot but there is still limitations.  Consider
this thread [1] about updating Git.  We do not have the capacity to let
QA check that all is fine.  Again considering [1], it appears to me
reasonable to ask that more than two people (Greg and I) give a look,
thus this thread [1] appears to me sane.

For some changes aside packages, QA is helpless.  Yeah we can improve
the Guix test suite and increase the coverage.  But still, for some
changes, the collateral effect is often hard to evaluate.  Hence, ask
for another look to be considered as green light appears to me fine.

I guess that the intent of this patch #61894 and I agree that the
wording is probably poor for that intent. :-)

Well, instead of closing, I think this patch requires an update.

Since Guix is growing and that’s a good thing, it implies two things:
(a) that more people are relying on it so for some part we need less
unexpected breakage and (b) that some implicit that worked until now
needs to be more explicit.

Yeah, the corollary of (a) is moving less fast for some part.  But there
is no free lunch. ;-)

And (b) does not mean strong all white or all black.

Cheers,
simon

1: <https://yhetil.org/guix/20230217180402.29401-1-code@greghogan.com/#r>