Re: Commitfest overflow - Mailing list pgsql-hackers

On 8/3/21 8:30 PM, Simon Riggs wrote:
> On Tue, 3 Aug 2021 at 17:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Bruce Momjian <bruce@momjian.us> writes:
>>> On Tue, Aug  3, 2021 at 04:53:40PM +0100, Simon Riggs wrote:
>>>> There are 273 patches in the queue for the Sept Commitfest already, so
>>>> it seems clear the queue is not being cleared down each CF as it was
>>>> before. We've been trying hard, but it's overflowing.
>>
>>> I wonder if our lack of in-person developer meetings is causing some of
>>> our issues to not get closed.
>>
>> I think there are a couple of things happening here:
>>
>> 1. There wasn't that much getting done during this CF because it's
>> summer and many people are on vacation (in the northern hemisphere
>> anyway).
>>
>> 2. As a community, we don't really have the strength of will to
>> flat-out reject patches.  I think the dynamic is that individual
>> committers look at something, think "I don't like that, I'll go
>> work on some better-designed patch", and it just keeps slipping
>> to the next CF.  In the past we've had some CFMs who were assertive
>> enough and senior enough to kill off patches that didn't look like
>> they were going to go anywhere.  But that hasn't happened for
>> awhile, and I'm not sure it should be the CFM's job anyway.
>>
>> (I hasten to add that I'm not trying to imply that all the
>> long-lingering patches are hopeless.  But I think some of them are.)
>>
>> I don't think there's much to be done about the vacation effect;
>> we just have to accept that the summer CF is likely to be less
>> productive than others.  But I'd like to see some better-formalized
>> way of rejecting patches that aren't going anywhere.  Maybe there
>> should be a time limit on how many CFs a patch is allowed to just
>> automatically slide through?
> 
> I guess the big number is 233 patches moved to next CF, out of 342, or
> 68% deferred.
> 
> Perhaps we need a budget of how many patches can be moved to next CF,
> i.e. CF mgr is responsible for ensuring that no more than ?50% of
> patches can be moved forwards. Any in excess of that need to join the
> kill list.
> 

How would this be different from the CFM just rejecting patches? It does 
not matter if there's an explicit number of patches that we allow to be 
moved to the next CF - someone still needs to make the decision, and I 
agree with Tom it probably should not be CFM's job.

IMO what the CFM can do is make an assessment, share it on the mailing 
list with a proposal to reject the patch, and leave the decision up to 
the patch author. Either the author accepts the view it's futile, or 
decides to keep working on it, solicits some reviews, etc.

> I would still ask for someone to spend a little time triaging things,
> so as to direct people who volunteer to be so directed. Many will not
> want to be directed, but I'm sure there must be 5-10 people who would
> do that? (Volunteers?)
> 


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company