Re: On commit access, patch review, and remaining healthy

[zimoun]

Hi,

On Wed, 08 Jun 2022 at 11:30, Giovanni Biscuolo <g@xelera.eu> wrote:

>> It reduces a bit the pressure on the committers, IMHO.
>
> It raises a bit the pressure on the maintainers, IMHO :-)

What does it mean “maintainer” here?

Maybe I miss something but I do not think the Guix maintainers play a
special role in reviewing or committing.  Could you explain which
pressure you are envisioning?


> I understand there is a certain "entrance barrier" to become patch
> reviewer, but I'm afraid we cannot lower it more than the current
> situation except for the offload build server and more tolling options.

I am missing the meaning of «tolling option».

I think it is possible to lower a bit the reviewing barrier.  Today, the
patch submission is very flexible: it is possible to send inline
patches, attached patches, mix inline and attach, subject can or not
contain ’vN’ and/or X/Y, base-commit is recommended but not mandatory,
etc.  Therefore, it is hard to automate many reviewing steps.

For instance, consider submission #47171 [1].  It was not my first
contribution, it was not the first review by Ricardo, and we both missed
a “guix pull” breakage despite the fact I did “make as-derivation” (and
I am not convinced it is systematically done ;-)).

Another example, when working of Preservation of Guix [2], I noticed
that many packages using git-fetch were not in SWH; which means that
“guix lint” had not been run on these packages.

We could answer more automated tools on infra side, etc. which is the
direction to go.  But we are not there yet and things need to be done
today. :-)  That’s why, I think the project should:

 1. change the default branch of “git push” vs the default branch of
 “guix pull”.

 2. add a bit more of checkers on patch submission easing patch review.
 

1: <https://issues.guix.gnu.org/47171#12>
2: 
<https://yhetil.org/guix/CAJ3okZ1Jv+ghZFLPhBVWTroamAfss66fkUzHAxorJx5P4Kjz3A@mail.gmail.com/>


Cheers,
simon