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