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
Re: Commitfest overflow Re: Commitfest overflow |
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: