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