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

From: "Greg Stark" <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: commitfest.postgresql.org is no longer fit for purpose
Date: 2024-05-16 20:14:07
Message-ID: CAM-w4HO09UcjUOVnZhnffMFyNm71AMQhvNVEaKy5=pS1G3-3pg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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....

On Thu, May 16, 2024, 21:48 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> >> On 16 May 2024, at 20:30, Robert Haas <robertmhaas(at)gmail(dot)com> 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
>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-05-16 20:17:54 gist index builds try to open FSM over and over
Previous Message Daniel Gustafsson 2024-05-16 20:11:41 Re: GUC names in messages