Re: Commitfest overflow

From: Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>
To: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Commitfest overflow
Date: 2021-08-03 18:34:01
Message-ID: CALtqXTebN=VgOAii3Hv7wz+_+i70vAjTp07e3Fw+U7Nb2iad8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 3, 2021 at 11:31 PM Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
wrote:

> On Tue, 3 Aug 2021 at 17:13, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Bruce Momjian <bruce(at)momjian(dot)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?)
>

Count me as a Volunteer.

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

--
Ibrar Ahmed

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2021-08-03 18:37:13 Re: Lowering the ever-growing heap->pd_lower
Previous Message Ibrar Ahmed 2021-08-03 18:32:50 Re: Commitfest overflow