Subject: Re: commitfest.postgresql.org is no longer fit for purpose

From: Tom Lane <[email-masked]>
Date: Thu, 16 May 2024 15:47:20 -0400

Daniel Gustafsson <[email-masked]> writes:
>> On 16 May 2024, at 20:30, Robert Haas <[email-masked]> wrote:
>> The original intent of CommitFests, and of commitfest.postgresql.org
>> by extension, was to provide a place where patches could be registered
>> to indicate that they needed to be reviewed, thus enabling patch
>> authors and patch reviewers to find each other in a reasonably
>> efficient way. I don't think it's working any more.

> But which part is broken though, the app, our commitfest process and workflow
> and the its intent, or our assumption that we follow said process and workflow
> which may or may not be backed by evidence?  IMHO, from being CMF many times,
> there is a fair bit of the latter, which excacerbates the problem.  This is
> harder to fix with more or better software though. 

Yeah.  I think that Robert put his finger on a big part of the
problem, which is that punting a patch to the next CF is a lot
easier than rejecting it, particularly for less-senior CFMs
who may not feel they have the authority to say no (or at
least doubt that the patch author would accept it).  It's hard
even for senior people to get patch authors to take no for an
answer --- I know I've had little luck at it --- so maybe that
problem is inherent.  But a CF app full of patches that are
unlikely ever to go anywhere isn't helpful.

It's also true that some of us are abusing the process a bit.
I know I frequently stick things into the CF app even if I intend
to commit them pretty darn soon, because it's a near-zero-friction
way to run CI on them, and I'm too lazy to learn how to do that
otherwise.  I like David's suggestion of a "Pending Commit"
status, or maybe I should just put such patches into RfC state
immediately?  However, short-lived entries like that don't seem
like they're a big problem beyond possibly skewing the CF statistics
a bit.  It's the stuff that keeps hanging around that seems like
the core of the issue.

>> I spent a good deal of time going through the CommitFest this week

> And you deserve a big Thank You for that.

+ many

			regards, tom lane

---

From: "Greg Stark" <[email-masked]>
Date: Thu, 16 May 2024 22:14:07 +0200

When I was CFM for a couple cycles I started with the idea that I was going
to try being a hardass and rejecting or RWF all the patches that had gotten
negative reviews and been bounced forward.

Except when I actually went through them I didn't find many. Mostly like
Robert I found perfectly reasonable patches that had received generally
positive reviews and had really complex situations that really needed more
analysis.

I also found a lot of patches that were just not getting any reviews at all
:( and rejecting those didn't feel great....

---

From: Joe Conway <[email-masked]>
Date: Thu, 16 May 2024 16:31:01 -0400

On 5/16/24 15:47, Tom Lane wrote:
> least doubt that the patch author would accept it).

Maybe we should just make it a policy that *nothing* gets moved forward 
from commitfest-to-commitfest and therefore the author needs to care 
enough to register for the next one?

>> And you deserve a big Thank You for that.

+1 agreed

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Jacob Champion <[email-masked]>
Date: Thu, 16 May 2024 13:57:05 -0700

> enough to register for the next one?

I think that's going to severely disadvantage anyone who doesn't do
this as their day job. Maybe I'm bristling a bit too much at the
wording, but not having time to shepherd a patch is not the same as
not caring.

--Jacob

---

From: Jesper Pedersen <[email-masked]>
Date: Thu, 16 May 2024 17:00:57 -0400

Hi,

> enough to register for the next one?

Or at least nothing get moved forward from March.

Spending time on a patch during a major version doesn't mean that you 
have time to do the same for the next major version.

That way July could start "clean" with patches people are interested in 
and willing to maintain during the next year.

Also, it is a bit confusing that f.ex.

  https://commitfest.postgresql.org/48/

already shows 40 patches as Committed...

So, having some sort of "End of Development" state in general would be good.

Best regards,
  Jesper

---

From: Joe Conway <[email-masked]>
Date: Thu, 16 May 2024 17:06:56 -0400

> wording, but not having time to shepherd a patch is not the same as

Maybe the word "care" was a poor choice, but forcing authors to think 
about and decide if they have the "time to shepherd a patch" for the 
*next CF* is exactly the point. If they don't, why clutter the CF with it.

---

From: Tom Lane <[email-masked]>
Date: Thu, 16 May 2024 17:08:09 -0400

> wording, but not having time to shepherd a patch is not the same as

Also, I doubt that there are all that many patches that have simply
been abandoned by their authors.  Our problem is the same as it's
been for many years: not enough review person-power, rather than
not enough patches.  So I think authors would just jump through that
hoop, or enough of them would that it wouldn't improve matters.

			regards, tom lane

---

From: Jacob Champion <[email-masked]>
Date: Thu, 16 May 2024 14:24:20 -0700

> *next CF* is exactly the point. If they don't, why clutter the CF with it.

Because the community regularly encourages new patch contributors to
park their stuff in it, without first asking them to sign on the
dotted line and commit to the next X months of their free time. If
that's not appropriate, then I think we should decide what those
contributors need to do instead, rather than making a new bar for them
to clear.

--Jacob

---

From: Joe Conway <[email-masked]>
Date: Thu, 16 May 2024 17:29:23 -0400

> contributors need to do instead, rather than making a new bar for them

If no one, including the author (new or otherwise) is interested in 
shepherding a particular patch, what chance does it have of ever getting 
committed?

IMHO the probability is indistinguishable from zero anyway.

Perhaps we should be more explicit to new contributors that they need to 
either own their patch through the process, or convince someone to do it 
for them.