Re: [Commitfest 2022-07] Patch Triage: Waiting on Author

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jacob Champion <jchampion(at)timescale(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Commitfest 2022-07] Patch Triage: Waiting on Author
Date: 2022-08-01 17:20:48
Message-ID: CA+TgmobCo92mY6W2t2T9AGxa2B=iCyVMdvVVutgxbso619F7aA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 1, 2022 at 12:56 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-08-01 17:33:12 Re: pg_auth_members.grantor is bunk
Previous Message Ranier Vilela 2022-08-01 17:08:48 Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)