Re: Commitfest overflow

> 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.