When I was CFM for a couple cycles I started with the idea that I was going to try being a hardass and rejecting or RWF all the patches that had gotten negative reviews and been bounced forward.
Except when I actually went through them I didn't find many. Mostly like Robert I found perfectly reasonable patches that had received generally positive reviews and had really complex situations that really needed more analysis.
I also found a lot of patches that were just not getting any reviews at all :( and rejecting those didn't feel great....
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 16 May 2024, at 20:30, Robert Haas <robertmhaas@gmail.com> wrote:
>> The original intent of CommitFests, and of commitfest.postgresql.org
>> by extension, was to provide a place where patches could be registered
>> to indicate that they needed to be reviewed, thus enabling patch
>> authors and patch reviewers to find each other in a reasonably
>> efficient way. I don't think it's working any more.
> But which part is broken though, the app, our commitfest process and workflow
> and the its intent, or our assumption that we follow said process and workflow
> which may or may not be backed by evidence? IMHO, from being CMF many times,
> there is a fair bit of the latter, which excacerbates the problem. This is
> harder to fix with more or better software though.
Yeah. I think that Robert put his finger on a big part of the
problem, which is that punting a patch to the next CF is a lot
easier than rejecting it, particularly for less-senior CFMs
who may not feel they have the authority to say no (or at
least doubt that the patch author would accept it). It's hard
even for senior people to get patch authors to take no for an
answer --- I know I've had little luck at it --- so maybe that
problem is inherent. But a CF app full of patches that are
unlikely ever to go anywhere isn't helpful.
It's also true that some of us are abusing the process a bit.
I know I frequently stick things into the CF app even if I intend
to commit them pretty darn soon, because it's a near-zero-friction
way to run CI on them, and I'm too lazy to learn how to do that
otherwise. I like David's suggestion of a "Pending Commit"
status, or maybe I should just put such patches into RfC state
immediately? However, short-lived entries like that don't seem
like they're a big problem beyond possibly skewing the CF statistics
a bit. It's the stuff that keeps hanging around that seems like
the core of the issue.
>> I spent a good deal of time going through the CommitFest this week
> And you deserve a big Thank You for that.
+ many
regards, tom lane