guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Enge
Subject: Re: Proposed changes to the commit policy (#59513)
Date: Sun, 22 Jan 2023 18:18:24 +0100

Am Wed, Jan 18, 2023 at 11:45:20AM +0000 schrieb Christopher Baines:
> > as a quick concrete question: Do simple package updates still count as
> > trivial, or do they need to go through the patches mailing list?
> 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.

So I tried it once, and find the hassle offputting. It feels like doubling
the effort - after doing the real work, I need to get back to it a week
later and more or less go through the motions again (rebase the commit
and resign it, recompile Guix, build the package again just in case),
plus the debbugs effort.

So expect even less package updates from my part in the future... These
were the kind of instant gratification actions one could do more or less
in the background, and they have become more complex administrative
endeavours with delayed gratification. (I also do not know how to set up
git-sendmail with my remote SMTP server login and password, but this is
a one-time cost of learning which does not matter that much.)

> > 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.

It would be nice to add this, yes.

Am Wed, Jan 18, 2023 at 04:54:58PM +0000 schrieb Kaelyn:
> 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.

This sounds like it could be a useful addition to the QA process.

Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]