Re: Commitfest 2024-01 first week update

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

In response to

Browse pgsql-hackers by date

  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?