Proposed changes to the commit policy (#59513)

Proposed changes to the commit policy (#59513)

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Hey!

A few weeks back, I sent a patch with some changes to the commit policy [1]:

  https://issues.guix.gnu.org/59513

There's already been some feedback and revisions which is great. The
policy also suggests guix-devel as a place for discussions regarding the
policy, hence I'm sending this email in case it's useful to anyone
interested.

Thanks,

Chris


1: https://guix.gnu.org/en/manual/devel/en/html_node/Commit-Access.html#Commit-Policy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

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

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]


Christopher Baines <mail@cbaines.net> writes:

> A few weeks back, I sent a patch with some changes to the commit policy [1]:
>
>   https://issues.guix.gnu.org/59513
>
> There's already been some feedback and revisions which is great. The
> policy also suggests guix-devel as a place for discussions regarding the
> policy, hence I'm sending this email in case it's useful to anyone
> interested.

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

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

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

[Ludovic Courtès]

Hello,

Christopher Baines <mail@cbaines.net> skribis:

> 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

Nice, thanks for pushing this forward!

Ludo’.

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

[Andreas Enge]

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

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

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?

Thanks for your help,

Andreas

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

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

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

[Kaelyn]

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

[Simon Tournier]

Hi Andreas,

On mer., 18 janv. 2023 at 12:23, Andreas Enge <andreas@enge.fr> wrote:

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

In addition to Chris words. :-)

From my point of view, the first question is if the package is a leaf or
not. :-)

Well, the main point, IMHO, of the policy (suggesting to go via
guix-patches) is to have an overview provided by qa.guix.gnu.org about
the status of all the dependents.

Being able to find all the dependents can be tricky; ’guix refresh -l’
is not always accurate because it misses some inheritance.  Consider the
case:

The package B is dependent of the package A.
The package C inherits from the package B.

Then, “guix refresh -l A“ will list only B and not C.  Although, a
change in the package A implies the rebuild of the package C.

Well, for a concrete example, please give a look at [1].  A “trivial”
and apparently inoffensive update of the package ’git’ from 2.38.0 to
2.38.1 breaks some Julia packages.  And, “guix refresh -l git” does not
mention these Julia packages.  The package ’git-minimal’ inherits from
’git’ and some Julia packages depends on ’git-minimal’.

1: <http://issues.guix.gnu.org/msgid/86wn7kd0m9.fsf@gmail.com>


All in all, going via guix-patches and let the build farm builds and
reports is a good way for avoiding potential breakages.


> but how is this specified in the email to the patch tracker,
> so that qa applies the patch to the correct branch?

I do not think the project has the resources to continuously build
core-updates.  That’s one of the points with core-updates: the
collateral effects of some patches in core-updates are only know “later“
– roughly speaking when it is decided to merge core-updates; I mean, the
current state of core-updates is highly variable and depends on many
factors (the type of patches, the number of people taking care of that
branch, etc.).


Cheers,
simon

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

[Andreas Enge]

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

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

[Simon Tournier]

Hi Andreas,

On Sun, 22 Jan 2023 at 18:18, Andreas Enge <andreas@enge.fr> wrote:

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

As mentioned here [1], it was possible to see the result of the QA for
this patch here:

    https://qa.guix.gnu.org/issue/60931

where the patch has been built on several architectures and all the
dependants too.  Now, because the patch had been pushed, this result is
not visible anymore. :-)

1: <http://issues.guix.gnu.org/msgid/864jsi1rkg.fsf@gmail.com>


That’s said, the patch had been built for all architectures and all the
dependants too, “guix lint” is applied systematically, etc.

For example, “guix lint” currently allows to be sure that the package is
archived in Software Heritage; maybe this will change in the future.

For what it is worth, I barely build for all the architectures the
patches I submit.  And I do not systematically rebuild all the
dependants because sometimes I “feel confident” it is a “trivial” change
that does not deserve such rebuild.  For sure, I do not remember rebuild
all the dependants for all the architectures.


Well, between the lines, are you suggesting that it is broken by design? :-)

Other said, it would not be possible to have the dashboard [2] all
green, right?  Because the QA provides some green lights for a state but
then you push to another state where the lights are unknown.

2: <http://ci.guix.gnu.org/eval/134159/dashboard>


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

While I understand this “extra“ work is a burden, what would you suggest
to reduce the number of broken packages?  Because all the red circles in
the dashboard [2] is a strong issue, IMHO.

When using Debian, I cross the fingers each time I run ‘apt upgrade’.
Using Guix, I cross the fingers each time I run ‘guix pull’.  Surprise,
surprise. :-)  Sometimes, the package that worked still works, sometimes
not.

This kind of example [3]:

        Well, for a concrete example, please give a look at [0].  A “trivial”
        and apparently inoffensive update of the package ’git’ from 2.38.0 to
        2.38.1 breaks some Julia packages.  And, “guix refresh -l git” does not
        mention these Julia packages.  The package ’git-minimal’ inherits from
        ’git’ and some Julia packages depends on ’git-minimal’.

        0: <http://issues.guix.gnu.org/msgid/86wn7kd0m9.fsf@gmail.com>

happens more than often.  Give a look at the dashboard. ;-) Obviously,
no blame. :-) Moreover, the complexity of all the parameters is not
tractable only by manual actions, IMHO.

At work, the feedback I often get is: Guix is not enough stable to daily
work and users cannot spend time to investigate if they are doing
something wrong or if it is broken.  People are fix again and again
something unrelated to their current task just because they did “guix
pull” (for having some new packages, some security fixes, etc.).

To avoid misunderstanding, I daily work with Guix and I am happy. :-)

Well, as I also wrote earlier [3]. :-) « We – from core developers to
user just wanting the things done – are all pulling the same branch.
This branch cannot satisfy in the same time all the constraints; is the
current push/pull branch model satisfying the best optimum with the
resource and tools at hand? »

Maybe the current full rolling-release applied to functional package
management does not scale well?

3: <https://yhetil.org/guix/86tu8xdlbw.fsf@gmail.com>


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

To my knowledge, it is not possible to continuously build core-updates
because the project does not have enough resource (both human power and
machine power).

Or do you mean mentioning this option of git-format-patch under point #9
of «Submitting Patches» [4]?  Because this option is already in the
manual under «Sending a Patch Series» section:

     Tip: To add a prefix to the subject of your patch, you may use the
     ‘--subject-prefix’ option.  The Guix project uses this to specify
     that the patch is intended for a branch or repository other than
     the ‘master’ branch of
     <https://git.savannah.gnu.org/cgit/guix.git>.

          git send-email -1 -a --base=auto \
              --subject-prefix='PATCH core-updates' \
              --to=guix-patches@gnu.org

4: <https://guix.gnu.org/manual/devel/en/guix.html#Submitting-Patches>


Cheers,
simon

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

[Attila Lendvai]

> While I understand this “extra“ work is a burden, what would you suggest
> to reduce the number of broken packages? Because all the red circles in
> the dashboard [2] is a strong issue, IMHO.


some random 0.02 follows from a non-committer. i don't think this would be a lot of extra burden, but i'm not sure how this scales up to several committers.

with that in mind:

besides the `master` branch, i would introduce a number of consequtive branches called `staging1`..`staging4`.

the more "problematic" a commit is, the deeper it should land in the stack of the staging branches.

commits are "promoted" stage-by-stage from staging4 towards master. the deeper we are in the stack, the less frequently it happens, and in larger batches. a major releases means promoting staging4 all the way up to master.

master is manually fast-forwarded to `staging1` every few days/hours, after checking the CI. this should be done by a dedicated person/role/group.

when master is updated, then an immediate attempt should also be made to rebase the staging branches on top of the new master. when this rebasing requires substantial effort, then it should be abandoned, and whoever is responsible for the problematic commits should do the rebasing.

all the branches are built automatically by the CI, but there's a strict priority: e.g. `staging2` is only built when `staging1` has finished building, or when manually requested by a maintainer.

the staging branches may be force-pushed, but the closer they are to master, the less haphazardly it should happen. when a committer sees that a history-rewrite is in order, they should drop a mail to the committer mailing list informing the others, and a "done" reply when finished (this would work better on a communication channel where deleting not-anymore-relevant messages is possible).

---------

further details:

LTS (Long Term Support): depending on the available human resources, when a major release is made, a branch (and a channel) could be opened for that release. this branch would receive backported fixes on a best effort basis. users, who want to delay dealing with the API changes introduced by the major release, may decide to stick to this channel for a while.

in the new setup master is always fully covered by the substitute servers. in the current setup i often find myself locally building large packages like chromium, which is a regular headache to me as a user.

compared to the current setup, `staging1` would be a new branch; rename `staging` -> `staging2`; `core-updates` -> `staging3`. API changes should land in `staging4`, waiting there until a major release.

this naming scheme is more intuitive for newcomers, but it might also be more error prone in everyday routine work.

HTH,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“To be human is not a fact, but a task.”
	— Søren Kierkegaard (1813–1855), paraphrased

Re: Proposed changes to the commit policy

[Andreas Enge]

Hello,

Am Mon, Jan 23, 2023 at 10:24:56AM +0100 schrieb Simon Tournier:
> > 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.
> To my knowledge, it is not possible to continuously build core-updates
> because the project does not have enough resource (both human power and
> machine power).

ah right, that is unfortunate.

> Or do you mean mentioning this option of git-format-patch under point #9
> of «Submitting Patches» [4]?  Because this option is already in the
> manual under «Sending a Patch Series» section:
> 
>      Tip: To add a prefix to the subject of your patch, you may use the
>      ‘--subject-prefix’ option.  The Guix project uses this to specify
>      that the patch is intended for a branch or repository other than
>      the ‘master’ branch of
>      <https://git.savannah.gnu.org/cgit/guix.git>.
> 
>           git send-email -1 -a --base=auto \
>               --subject-prefix='PATCH core-updates' \
>               --to=guix-patches@gnu.org

Okay, I did not notice this; so if this is already implemented, even better!

On the other subject, I just updated mpfr and mpc on core-updates, and hope
that everything will build (with reason, the changes to these projects are
rather conservative in general).

Andreas

Re: Proposed changes to the commit policy

[Ludovic Courtès]

Hi!

My 2¢ on this…  As a committer & reviewer, I love that I can just go to
<https://qa.guix.gnu.org/patches>, pick one of the patch series with a
green tick, and have the assurance that the resource-intensive work is
already done.  That makes a big difference!

As someone who submits patches, I realize the delay can be off-putting.
For the hwloc upgrade I recently submitted, I got valuable feedback
pointing at actual issues, but that was about a week later.  Then I had
to switch contexts again to adjust the patch accordingly.

I guess that, to a large extent, that’s scheduling and resource issue.

Happy to discuss that in the coming days in Brussels!

Ludo’.

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

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]


Andreas Enge <andreas@enge.fr> writes:

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

I appreciate feeling put off by this, although I'd maybe reframe it as
balancing quality with other factors, and how that's going to change for
Guix as a project over time.

In the past and currently to some extent, it's been possible to move
very quickly without comprimising on quality. However, my feeling on
this is that if we want to have quality support for non x86_64-linux
architectures, reproducible builds, packages that build reliably,
... then that's going to require more effort. That might mean some
changes happen more slowly, but this is why I'm working on the tools and
processes, as I think that's a path to trying to maintain and improve
the quality while reducing the impact to pace and enjoyment.

I'm sure there are ways of addressing at least some of the problems you
mention above, so it's really valuable to mention them so that we can
work towards solutions.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

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

[Simon Tournier]

Hi,

On Mon, 30 Jan 2023 at 22:03, Christopher Baines <mail@cbaines.net> wrote:

> In the past and currently to some extent, it's been possible to move
> very quickly without comprimising on quality. However, my feeling on
> this is that if we want to have quality support for non x86_64-linux
> architectures, reproducible builds, packages that build reliably,
> ... then that's going to require more effort. That might mean some
> changes happen more slowly, but this is why I'm working on the tools and
> processes, as I think that's a path to trying to maintain and improve
> the quality while reducing the impact to pace and enjoyment.

I agree.

For what it is worth, this kind of slow transition seems common to many
projects. :-) For example, a recent story about Yocto [1].  Teaser:

        Our scale also means patch requirements are more demanding
        now. Once, when the number of people using the project was
        small, the impact of breaking things was also more limited,
        allowing a little more freedom in development. Now, if we accept
        a change commit and something breaks, it becomes an instant
        emergency, […]

Well, happy to discuss in Brussels or elsewhere such topic: being more
reliable with fun. :-)

Cheers,
simon


(From LWN [2] ;-))

1: <https://www.linux.com/audience/maintainer-confidential-opportunities-and-challenges-of-the-ubiquitous-but-under-resourced-yocto-project/>
2: <https://lwn.net/Articles/921646/>

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

[Andreas Enge]

Am Mon, Jan 30, 2023 at 10:03:14PM +0000 schrieb Christopher Baines:
> changes happen more slowly, but this is why I'm working on the tools and
> processes, as I think that's a path to trying to maintain and improve
> the quality while reducing the impact to pace and enjoyment.
> I'm sure there are ways of addressing at least some of the problems you
> mention above

One idea that came to my mind is that once the patch passes all tests
in automatic quality assurance, it could be committed automatically and
the bug closed (well, maybe not any patches, but at least these kind of
update patches, or specially tagged ones). This would not force people
to get back to them.

However I think it cannot work, since it means rebasing on the current
master, which invalidates the signature of the commit.

Andreas

Re: Proposed changes to the commit policy

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Mon, Jan 30, 2023 at 10:40:42PM +0100, Ludovic Courtès wrote:
> Hi!
> 
> My 2¢ on this…  As a committer & reviewer, I love that I can just go to
> <https://qa.guix.gnu.org/patches>, pick one of the patch series with a
> green tick, and have the assurance that the resource-intensive work is
> already done.  That makes a big difference!
> 
> As someone who submits patches, I realize the delay can be off-putting.
> For the hwloc upgrade I recently submitted, I got valuable feedback
> pointing at actual issues, but that was about a week later.  Then I had
> to switch contexts again to adjust the patch accordingly.
> 
> I guess that, to a large extent, that’s scheduling and resource issue.
> 
> Happy to discuss that in the coming days in Brussels!

Some of that might be mitigated by separating submitting patches and
pushing patches. On the rare occasion I've pushed patches belonging to
another committer if I felt it had been long enough and I needed it for
another patchset. If we're ok with touching up and pushing each other's
patches then reviewing all patches might go faster.

Even more so if we made it a rule that you couldn't push your own
patches (which I believe was suggested in 2017 and with using aegis).

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]