Re: Commitfest overflow - Mailing list pgsql-hackers

On Tue, Aug 3, 2021 at 2:52 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> 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.
>
> IMO what the CFM can do is make an assessment, share it on the mailing
> list with a proposal to reject the patch, and leave the decision up to
> the patch author. Either the author accepts the view it's futile, or
> decides to keep working on it, solicits some reviews, etc.

I don't really agree with this. Not all decisions can or should be
made collaboratively.

In particular, I think CfM's have been pretty timid about bouncing
stuff that isn't really showing signs of progress. If a patch has been
reviewed at some point in the past, and say a month has gone by, and
now we're beginning or ending a CommitFest, the patch should just be
closed. Otherwise the CommitFest just fills up with clutter. It's not
the worst thing in the world to ask on the thread, "hey, can we RwF
this?" but it risks delaying a decision that ought to have been
automatic. Patches that are not being updated regularly have no
business being part of a CommitFest.

Also, if it's clear that an idea has quite a bit of opposition, it
should be RwF'd or rejected, even if the patch author doesn't agree.
Nothing whatever keeps the patch author from continuing to argue about
it, or indeed resubmitting the patch. But we don't get any value out
of having a list of things that somebody should take a look at which
includes things that have been looked at already and judged by
multiple people to be not acceptable. I don't think a patch should be
rejected on the strength of a single -1, but when 2 or 3 people have
shown up to say either that they don't like the idea or that the
implementation is way off base, it's not helpful to leave things in a
state that suggests it needs more eyeballs.

Arguing with people about the merits of a patch that has a 0%
probability of being committed by anybody is one of my least favorite
things. I have only so much time, and I want to invest the time I have
in things that have a chance of getting someplace. I don't mind the
time spent telling somebody whose patch is bad why it has no hope -
and I think that's an important thing for us to do. But if somebody
thinks, say, that full page writes are not needed and we should just
remove them, I only want to explain why they are wrong. I don't want
to argue about whether they are actually right. There are plenty of
patches where somebody has ideas that may or may not be good and we
should talk about it - but there are also some where talking isn't
going to help, and those can easily consume massive amounts of time
and energy.

-- 
Robert Haas
EDB: http://www.enterprisedb.com