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

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

In response to

Responses

Browse pgsql-hackers by date

  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!