Re: Guix Days: Patch flow discussion

["Clément Lassieur" <clement@lassieur.org>]

On Mon, Feb 05 2024, Suhail wrote:

> Tomas Volf <~@wolfsden.cz> writes:
>
>> In ideal world, there would always be *some* reaction from the
>> project, even if that reaction would be "we do not want this change".
>
> Agreed.  A reduction in the time between a patch (or patch revision)
> submission and a review/reaction would be a positive change in my
> opinion.
>
>> Even if it would be just an auto-close (for the "contributor can't
>> work effectively..." case).
>
> Are there current instances of "contributor can't work effectively"?  If
> not, I propose that decisions concerning those situations be deferred
> till we have actual instances to guide us.
>
>> Or, to put it in a different way: The problem is not that too few patches get
>> merged.  The problem is that too few patches get reviewed.
>
> Agreed.
>
> I believe the below steps would help with the current situation, and
> perhaps both should be pursued (among possibly others).
>
> 1. It would help to eliminate the need for review in certain kinds of
>    patches.  Some version upgrades for a package $foo where there exists
>    no package $bar that depends on $foo may fall in this category.  More
>    generally, some "known to be safe with reasonable confidence" changes
>    may be safe to be auto-committed without needing manual review.

I think "auto-commit" is a bit too much, but tagging a patch as "can be
pushed" could make it easy for committers to find them and push them.

>    Recognizing such changes could be challenging, but we don't have to
>    correctly label all such changes in order for this to be helpful.
>
> 2. It would help if it were easier for the community to be able to identify the next
>    steps, given a patch submission.  It might help to (more?) clearly
>    differentiate between the below states:
>    - patch *needs review* (automatically set)
>    - patch *needs revision* (set explicitly by the reviewer, say, by
>      using a specific keyword in their email)
>    - patch *needs followup review* (automatically set if there's a
>      revised patch)
>    - patch has a *satisfied reviewer* (set explicitly by the reviewer,
>      say, by using a specific keyword in their email)

+1

Ideally with debbugs tags.

(Patches that don't need review should be tagged as well.)