[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix Days: Patch flow discussion
From: |
Clément Lassieur |
Subject: |
Re: Guix Days: Patch flow discussion |
Date: |
Mon, 05 Feb 2024 18:36:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.)
- Re: Guix Days: Patch flow discussion, (continued)
Re: Guix Days: Patch flow discussion, Simon Tournier, 2024/02/15
Re: Guix Days: Patch flow discussion, Suhail, 2024/02/05
Re: Guix Days: Patch flow discussion,
Clément Lassieur <=
Re: Guix Days: Patch flow discussion, Suhail, 2024/02/05
Re: Guix Days: Patch flow discussion, Suhail, 2024/02/05
Re: Guix Days: Patch flow discussion, Andy Tai, 2024/02/05