| From: | Jacob Champion <jchampion(at)timescale(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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:43:06 |
| Message-ID: | 8a2e18d1-0a77-47cc-4651-5d3491542f1c@timescale.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-08-01 16:44:14 | Re: [Commitfest 2022-07] is Done! |
| Previous Message | Simon Riggs | 2022-08-01 16:42:49 | Smoothing the subtrans performance catastrophe |