Re: Commitfest overflow - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Commitfest overflow
Date
Msg-id 1717888.1628007224@sss.pgh.pa.us
Whole thread Raw
In response to Re: Commitfest overflow  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Commitfest overflow
Re: Commitfest overflow
Re: Commitfest overflow
List pgsql-hackers
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?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Next
From: Matthias van de Meent
Date:
Subject: Re: Lowering the ever-growing heap->pd_lower