Re: Commitfest Update

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Commitfest Update
Date: 2022-07-15 23:15:32
Message-ID: 20220715231531.GQ18011@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 15, 2022 at 03:17:49PM -0700, Jacob Champion wrote:
> > Also, cfapp has a page for "patches where you are the author", but the cfbot
> > doesn't,
>
> (I assume you mean "reviewer"?)

Yes

> Also, I would like to see us fold cfbot output into the official CF,
> rather than do the opposite.

That's been the plan for years :)

> > I'd prefer to see someone
> > pick one of the patches that hasn't seen a review in 6 (or 16) months, and send
> > out their most critical review and recommend it be closed, or send an updated
> > patch with their own fixes as an 0099 patch.
>
> That would be cool, but who is "someone"? There have been many, many
> statements about the amount of CF cruft that needs to be removed. Seems
> like the CFM is in a decent position to actually do it.

I have hesitated to even try to begin the conversation.

Since a patch author initially creates the CF entry, why shouldn't they also be
responsible for moving them to the next cf. This serves to indicate a
continued interest. Ideally they also set back to "needs review" after
addressing feedback, but I imagine many would forget, and this seems like a
reasonable task for a CFM to do - look at WOA patches that pass tests to see if
they're actually WOA.

Similarly, patches could be summarily set to "waiting on author" if they didn't
recently apply, compile, and pass tests. That's the minimum standard.
However, I think it's better not to do this immediately after the patch stops
applying/compiling/failing tests, since it's usually easy enough to review it.

It should be the author's responsibility to handle that; I don't know why the
accepted process seems to involve sending dozens of emails to say "needs
rebase". You're putting to good use of some cfapp email features I don't
remember seeing used before; that seems much better. Also, it's possible to
subscribe to CF updates (possibly not a well-advertised, well-known or
well-used feature).

I didn't know until recently that when a CF entry is closed, that it's possible
(I think) for the author themselves to reopen it and "move it to the next CF".
I suggest to point this out to people; I suppose I'm not the only one who finds
it offputting when a patch is closed in batch at the end of the month after
getting only insignificant review.

Thanks for considering

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-07-15 23:16:46 Moving RwF patches to a new CF
Previous Message David Rowley 2022-07-15 23:12:07 Re: PG15 beta1 sort performance regression due to Generation context change