From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Commitfest 2024-01 first week update |
Date: | 2024-02-07 14:14:40 |
Message-ID: | 7F21B639-6441-4A52-BEC9-B49F2EECDF03@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 7 Feb 2024, at 14:15, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2024-Feb-07, Daniel Gustafsson wrote:
>
>> Since the CF app knows when the last email in the thread was, the
>> state of the patch entry and the number of CF's which is has been
>> present in; maybe we can extend the app to highlight these patches in
>> a way which doesn't add more manual intervention? It might yield a
>> few false positives, but so will setting it manually.
>
> Hmm, but suppose the author is posting new versions now and again
> because of apply conflicts; and the CFM is pinging them about that, but
> not providing any actionable feedback. Such a thread would be active
> enough, but the patch is still stalled.
If the patch author is actively rebasing the patch and thus generating traffic
on the thread I'm not sure I would call it stalled - there might not be enough
(or any) reviews but the activity alone might make someone interested. Either
way, I'd personally prefer such false positives if it means reducing the manual
workload for the CFM.
--
Daniel Gustafsson
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2024-02-07 14:43:23 | Re: Set log_lock_waits=on by default |
Previous Message | Peter Eisentraut | 2024-02-07 14:05:16 | What about Perl autodie? |