| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com> |
| Cc: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tomas Vondra <tomas(at)vondra(dot)me>, Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: new commitfest transition guidance |
| Date: | 2025-02-06 18:18:56 |
| Message-ID: | 1135387.1738865936@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com> writes:
> What if we automatically move any patches to the current commitfest if new
> patch attachments are sent to the corresponding message thread? Heck,
> perhaps if there are any new messages *at all* in the message thread, and
> the commitfest entry has not been closed already, we should move it to the
> current commitfest.
+1 ... this would go a long way towards reducing the manual effort
needed to maintain these things.
> We could even have commitfest respond to the message
> thread to inform when automated actions of this nature have been taken.
Dunno that we need automated mail about it though.
(I don't care for the other idea of not having dated CFs at all.
That would mean that an entry never disappears unless manual action
is taken to remove it. Making untouched threads silently age out
seems like the better path forward.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2025-02-06 18:41:20 | Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary |
| Previous Message | Tom Lane | 2025-02-06 18:14:54 | Re: "Type does not exist" error when returning array of type in non-public schema |