From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jacob Champion <jchampion(at)timescale(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(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 16:56:15 |
Message-ID: | 1848879.1659372975@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jacob Champion <jchampion(at)timescale(dot)com> writes:
> On 8/1/22 09:33, Robert Haas wrote:
>> We really need to move to a system where it's the patch author's job
>> to take some action if the patch is alive, rather than having the CM
>> (or any other human being) pinging to find out whether it's dead.> Having the default action for a patch be to carry it along to the next
>> CF whether or not there are any signs of life is unproductive.
> In the medium to long term, I agree with you.
> In the short term I want to see the features that help authors keep
> their patches alive (cfbot integration! automatic rebase reminders!
> automated rebase?) so that we're not just artificially raising the
> barrier to entry. People with plenty of time on their hands will be able
> to go through the motions of moving their patches ahead regardless of
> whether or not the patch is dead.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-08-01 17:00:43 | Re: pg_auth_members.grantor is bunk |
Previous Message | Tom Lane | 2022-08-01 16:44:14 | Re: [Commitfest 2022-07] is Done! |