Re: Commitfest overflow - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Commitfest overflow
Date
Msg-id CANbhV-FRsRx6ppWESbHRhLikPyxnSPU+xZQw-aa_C6WBU3vJvw@mail.gmail.com
Whole thread Raw
In response to Re: Commitfest overflow  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Commitfest overflow  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
Re: Commitfest overflow  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Re: Commitfest overflow  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.

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

-- 
Simon Riggs                http://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Remove unused 'len' from pg_stat_recv_* functions
Next
From: Ibrar Ahmed
Date:
Subject: Re: Commitfest overflow