| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jacob Champion <jchampion(at)timescale(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:33:52 |
| Message-ID: | CA+Tgmoab=R7uwPqqG6o9xHN0=vRrptTqQQe3tUBm=FML=y2KUQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Aug 1, 2022 at 12:30 PM Jacob Champion <jchampion(at)timescale(dot)com> wrote:
> Maybe this is something to look into once we've implemented some more of
> the low-hanging usability features that people have asked for. But if we
> started doing it now, I'd expect the CFM's job to simply change from
> moving patches ahead to pinging people who have patches left behind,
> asking them if they meant to move the patches forward. I'm not convinced
> it'd be all that useful.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2022-08-01 16:42:49 | Smoothing the subtrans performance catastrophe |
| Previous Message | Jacob Champion | 2022-08-01 16:30:39 | Re: [Commitfest 2022-07] Patch Triage: Waiting on Author |