On Wed, Jan 20, 2016 at 12:40:04PM -0500, Tom Lane wrote:
> I think it might also be a good idea if we could somehow distinguish
> "nobody had time for that yet" from "nobody is interested", with an eye
> to flat-out rejecting patches that no one cares enough about to review.
> Maybe we could reduce the workload by inventing some kind of up-front
> filter whereby a patch isn't even a candidate to get reviewed unless, say,
> at least two people besides the author say "this sounds like it's worth
> pursuing".
>
> One of the other things I do not like about the current CF process is that
> it's created a default assumption that most submitted patches should get
> accepted eventually. It is *very* hard to reject a patch altogether in
> the CF process: you more or less have to show cause why it should not get
> accepted. That default is backwards. Maybe this isn't the process' fault
> exactly, but it sure seems like that's how we approach patches now.
These paragraphs point to different facets of the same problem: community
conventions make rejecting a patch a substantial project in its own right. +1
for experimenting with one or more ways to expedite that. There's your
two-ACKs idea above, and we floated[1] a few more at the 2015-06-16 meeting:
This was followed by discussion of how we arrange the CFs. Noah suggested a prioritization system. He suggested a
systemwhere various committers can provide feedback on stuff as triage. Simon agreed and volunteered. Haas suggested a
2-committerveto. Frost said we need a formal way to "nack" something. We need to triage stuff earlier in the process.
Haassays the big problem is the endless arguments because we don't want to say "no" to people because we have scarce
committertime.
I recommend trying the two-ACKs plan for one CF. Keep it if it helps
markedly; otherwise, try another of these variants for the CF after that one.
Thanks,
nm
[1] https://wiki.postgresql.org/wiki/PgCon_2015_Developer_Meeting#9.6_Schedule