[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed changes to the commit policy (#59513)
From: |
Kaelyn |
Subject: |
Re: Proposed changes to the commit policy (#59513) |
Date: |
Wed, 18 Jan 2023 16:54:58 +0000 |
------- 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
- Re: Proposed changes to the commit policy (#59513), Christopher Baines, 2023/01/16
- Re: Proposed changes to the commit policy (#59513), Ludovic Courtès, 2023/01/17
- Re: Proposed changes to the commit policy (#59513), Andreas Enge, 2023/01/18
- Re: Proposed changes to the commit policy (#59513), Christopher Baines, 2023/01/18
- Re: Proposed changes to the commit policy (#59513),
Kaelyn <=
- Re: Proposed changes to the commit policy (#59513), Andreas Enge, 2023/01/22
- Re: Proposed changes to the commit policy (#59513), Simon Tournier, 2023/01/23
- Re: Proposed changes to the commit policy (#59513), Attila Lendvai, 2023/01/24
- Re: Proposed changes to the commit policy, Andreas Enge, 2023/01/25
- Re: Proposed changes to the commit policy, Ludovic Courtès, 2023/01/30
- Re: Proposed changes to the commit policy (#59513), Christopher Baines, 2023/01/30
- Re: Proposed changes to the commit policy (#59513), Simon Tournier, 2023/01/31
Re: Proposed changes to the commit policy (#59513), Simon Tournier, 2023/01/20