Re: Finding worthy commitfest entries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Finding worthy commitfest entries
Date: 2026-09-14 15:31:27
Message-ID: 126431.1789399887@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Sabino Mullane <htamfids(at)gmail(dot)com> writes:
> [ How to find CF entries that need love? ]

> Some ideas:

> * More peer pressure to have people populate the Reviewer field.
> Maybe not 'peer' so much as the commitfest manager. :)

> * Let logged-in users add other people as reviewers. If I'm already opening
> up the archived discussion, I could easily throw some names in as reviewers
> from the thread. Then I can easily skip it next time.

I think this is already possible by editing the CF entry -- at least,
I know I've been added as reviewer to some entries where I didn't ask
for that. I find that extremely discourteous and usually remove
myself immediately. To my mind anyway, being listed as reviewer
implies some ongoing time commitment, and nobody has any business
co-opting my time like that. So I'm -1 on this suggestion. But
yeah, we should encourage people to add themselves when they have
an interest.

> * Have the main page show the number of emails in the thread.

+1 on this idea. It seems useful and I figure it must be quite
easy to obtain since the app is scanning the thread already.

> * Have the main page show the number of distinct people in the thread.

Perhaps. It'd be good to be able to see whether anyone but the patch
author(s) have commented.

> * Have LLM give it a score and/or text summary, indicating how active it
> is, and the likelihood of it needing a reviewer.

> * Allow the author (maybe others) to add a flag such as "no reviewer yet"
> or "help needed"

Neither of those thoughts excite me too much. You can already see
whether there's a reviewer signed up.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2026-09-14 15:45:09 Re: [PATCH] pg_dump: Restore extension config table data before user objects during pg_upgrade
Previous Message shihao zhong 2026-09-14 15:29:49 Re: Opportunistic pruning is lost under direct io, and nothing shows it