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

[Kaelyn <kaelyn.alexi@protonmail.com>]

------- Original Message -------
On Wednesday, January 18th, 2023 at 11:45 AM, Christopher Baines <mail@cbaines.net> wrote:
> 
> 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.

On a side note, I'd recently discovered the flag to pass. To have a subject prefix like "[PATCH core-updates]" (as mentioned in the manual for staging and core-updates patches) instead of the default "[PATCH]", one can pass "--subject-prefix="PATCH core-updates" to git format-patch.

Cheers,
Kaelyn

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