Re: Commitfest 2022-03 Patch Triage Part 1a.i - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Commitfest 2022-03 Patch Triage Part 1a.i
Date
Msg-id 20220302172854.wvmfj26nh2umuw3y@jrouhaud
Whole thread Raw
In response to Re: Commitfest 2022-03 Patch Triage Part 1a.i  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Wed, Mar 02, 2022 at 11:58:28AM -0500, Greg Stark wrote:
>
> But I'm unclear exactly what the consequences in the commitfest app
> are of specific state changes. As I understand it there are basically
> two alternatives:
>
> 1) Returned with feedback -- does this make it harder for an author to
> resume work release? Can they simply reactivate the CF entry or do
> they need to start a new one and then lose history in the app?

As far as I know they would need to create a new entry, and thus lose the
history.

> 2) Moved to next commitfest -- this seems to just drag the pain on.
> Then it has to get triaged again next commitfest and if it's actually
> stalled (or progressing fine without needing feedback) that's just
> extra work for nothing.
>
> Do I have this right? What is the right state to put a patch in that
> means "this patch doesn't need to be triaged again unless the author
> actually feels progress has been made and needs new feedback or thinks
> its committable"?

I don't think that 2) means having to triage again.  If a patch gets moved to
the next commitfest now, then clearly it's not ready and should be also
switched to Waiting on Author.

In the next commitfest, if the author doesn't address the problems raised
during review the patch will still be in Waiting for Author, and the only
needed triaging would be to close as Return With Feedback patches that looks
abandoned.  For now the arbitrary "abandoned" definition is usually "patch in
Waiting on Author for at least 2 weeks at the end of the commitfest with no
sign of activity from the author".



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Commitfest 2022-03 Patch Triage Part 1a.i
Next
From: Robert Haas
Date:
Subject: Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?