Re: Triage on old commitfest entries

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Triage on old commitfest entries
Date: 2021-10-03 20:18:24
Message-ID: CAH2-WznZP+My4UzrR8c0g0_-gNgNo1CxsrNpnpKHQnZ6A0_MJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 3, 2021 at 12:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> An important note to make here is that we don't have any explicit
> mechanism for saying "sorry, this patch is perhaps useful but it
> seems that nobody is going to take an interest in it". Closing
> such a patch as "rejected" seems harsh, but R-W-F isn't very
> appropriate either if the patch never got any real review.
> Perhaps we should create a new closure state?

We don't reject patches, except in very rare cases where the whole
concept is wildly unreasonable, or when the patch author decides to
mark their own patch rejected. In other words, we only reject patches
where the formal status of being rejected hardly matters at all. I
have to wonder what the point of the status of "rejected" really is.
Ambiguity about what the best way forward is seems to be the thing
that kills patches -- it is seldom mistakes or design problems. They
can usually be corrected easily. Sometimes the ambiguity is very
broad, other times it's just one aspect of the design (e.g., the
planner aspects).

I'd rather go in the opposite direction here: merge "Rejected" and
"Returned with Feedback" into a single "Patch Returned" category
(without adding a third category). The odds of a CF entry that gets
marked R-W-F eventually being committed is, in general, totally
unclear, or seems to be. I myself have zero faith that that status
alone predicts anything, good or bad. I think that under-specifying
why a patch has been returned like this would actually be *more*
informative. Less experienced contributors wouldn't have to waste
their time looking for some signal, when in fact there is little more
than noise.

> Index Skip Scan 16
> Last substantive discussion 2021-05, currently passing cfbot
>
> Seems possibly useful, but we're not making progress.

This feature is definitely useful. My pet theory is that it hasn't
made more progress because it requires expertise in two fairly
distinct areas of the system. There is a lot of B-Tree stuff here,
which is clearly my thing. But I know that I personally am much less
likely to work on a patch that requires significant changes to the
planner. Maybe this is a coordination problem.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-03 20:30:29 Re: Triage on old commitfest entries
Previous Message Tom Lane 2021-10-03 20:16:39 Re: Triage on old commitfest entries - JSON_PATH