Re: [Commitfest 2022-07] Patch Triage: Waiting on Author - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [Commitfest 2022-07] Patch Triage: Waiting on Author
Date
Msg-id CA+TgmobCo92mY6W2t2T9AGxa2B=iCyVMdvVVutgxbso619F7aA@mail.gmail.com
Whole thread Raw
In response to Re: [Commitfest 2022-07] Patch Triage: Waiting on Author  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [Commitfest 2022-07] Patch Triage: Waiting on Author
List pgsql-hackers
On Mon, Aug 1, 2022 at 12:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, I don't want to introduce make-work into the process; there's
> more than enough real work involved.  At minimum, a patch that's
> shown signs of life since the previous CF should be auto-advanced
> to the next one.

Maybe so, but we routinely have situations where a patch hasn't been
updated in 3-6 months and we tentatively ask the author if it would be
OK to mark it RwF, and they often say something like "please keep it
alive for one more CF to see if I have time to work on it." IMHO, that
creates the pretty ridiculous situation where CFMs are putting time
into patches that the author isn't working on and hasn't worked on in
a long time. The CF list isn't supposed to be a catalog of every patch
somebody's thought about working on at any point in the last few
years; it's supposed to be a list of things that need to be reviewed
for possible commit. That's why it's called a COMMIT-fest.

Back in the day, I booted patches out of the CF if they weren't
updated within 4 days of a review being posted. I guess people found
that too harsh, but now it feels like we've gone awfully far towards
the other extreme.

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



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Next
From: Robert Haas
Date:
Subject: Re: pg_auth_members.grantor is bunk