Re: Commitfest 2022-03 Patch Triage Part 1a.i

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Commitfest 2022-03 Patch Triage Part 1a.i
Date: 2022-03-02 17:28:17
Message-ID: 3050135.1646242097@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> Do I have this right? What is the right state to put a patch in that
> means "this patch doesn't need to be triaged again unless the author
> actually feels progress has been made and needs new feedback or thinks
> its committable"?

But that's not really the goal, is it? ISTM what you want to do is
identify patches that we're not going to try to get into v15, and
then push them out to the next CF so that we don't spend more time
on them this month. But that determination should not preclude them
from being looked at on the normal basis once the next CF arrives.
So I'd say just push them forward with status "Needs review" or
"Waiting on author", whichever seems more appropriate.

If a patch seems to have stalled to the point where neither of
those statuses is appropriate, then closing it RWF would be the
thing to do; but that's not special to the last-CF situation.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-03-02 17:28:54 Re: Commitfest 2022-03 Patch Triage Part 1a.i
Previous Message David Steele 2022-03-02 17:24:24 Re: pg_stop_backup() v2 incorrectly marked as proretset