Re: Proposed changes to the commit policy (#59513)

[Christopher Baines]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> Am Mon, Jan 16, 2023 at 09:47:06PM +0000 schrieb Christopher Baines:
>> I merged the changes a few days ago, so this is just a quick message to
>> say that the commit policy has changed. You can read the updated policy
>> here:
>>   
>> https://guix.gnu.org/en/manual/devel/en/html_node/Commit-Access.html#Commit-Policy
>
> as a quick concrete question: Do simple package updates still count as
> trivial, or do they need to go through the patches mailing list?
> I intended to update pari-gp from 2.15.1 to 2.15.2, as usual by checking
> that all dependent packages still compile. Having to fiddle with debbugs
> is somewhat deterring (although admittedly having qa compile all dependent
> packages is also a service in a context where I do not expect problems).

My feeling on this is that "simple" package updates are often not
trivial, or at least doing rigorous testing for these updates isn't
trivial. A definition of trivial might be "having little value or
importance", and I don't think that's generally the case for version
updates, they're often a valuable and important change.

That's not to say that the policy doesn't allow for pushing the pari-gp
update directly to the master branch. I think the wiggle room in the
policy is given by the "should" instruction regarding posting to
guix-patches@gnu.org and the "This is subject to being adjusted,
allowing individuals to commit directly on non-controversial changes on
parts they’re familiar with." bit.

As you say, my hope is that having parts of the quality assurance
testing automated, e.g. compiling the updated version of para-gp and
affected packages on supported architectures will be something people
want to use, rather than feeling forced to.

> In case the answer is that submitting to the patch tracker is required,
> I would suggest to shorten the waiting period from one week to zero
> (meaning that it is okay to push when there are no problems detected by qa,
> without having to wait for human review that has no reason to occur).

That seems reasonable to me, at least in the case of package
updates. Given that's such a common change, maybe that needs handling
specifically in the commit policy.

> I would also like to update mpfr and mpc in core-updates. The documentation
> mentions the different branches under Step 9:
>    https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html
> but how is this specified in the email to the patch tracker,
> so that qa applies the patch to the correct branch?

That's not something that's attempted yet, all patches are just applied
to master. Maybe setting out the subject like this [1] could indicate
the intended branch? I'm not sure what flags to pass to git
format-patch/send-email to achieve that though.

1: https://issues.guix.gnu.org/55227

signature.asc
Description: PGP signature