Re: Commitfest overflow - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Commitfest overflow
Date
Msg-id 20210807193245.ausoqtelo2bup76i@localhost
Whole thread Raw
In response to Re: Commitfest overflow  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
> On Tue, Aug 03, 2021 at 02:57:49PM -0400, Bruce Momjian wrote:
>
> On Tue, Aug  3, 2021 at 08:51:57PM +0200, Tomas Vondra wrote:
> > 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.
>
> My experience with the query id patch is that it can't be rejected
> because everyone wants it, but it needs work to get it in a state that
> everyone approves of.  Sometimes it is impossible for the patch author
> to figure that out, and I needed Álvaro Herrera's help on the query id
> patch, so even I wasn't able to figure it out alone.

I know I'm late to the party, but I couldn't stop thinking about this
thread.  Since there seems to be no specific changes agreed upon in
here, I wanted to add my 5c.

It's indeed hard at times to use CF app efficiently due to cluttering of
different sorts:

* Patches slipping through CFs "waiting on author".  Hopefully CFM can
  identify such cases without much efforts.

* Patches slipping through CFs on "needs review", while, as you mention,
  sometimes it is hard for the author to figure something out and an
  attention of more knowledgeable hacker is needed.  Most of the time
  this status means "needs a design review" (which should be probably
  even introduced as a real status), and such review is indeed a scarce
  resource in the community.  Due to that a certain level of cluttering
  is unavoidable in the long term I believe, no matter how many hackers
  will go triaging things.

* Bloat in the official reviewers field, which was mentioned at the
  start.  I believe there were suggestions in the past to address this
  via resetting the field automatically on the start of every CF.

  As a side note, maybe one could go even further in resetting /
  automation and put the responsibility for moving patches between CF
  fully on shoulders of the authors.



pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Michael Meskes
Date:
Subject: Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE