Re: 2022-01 Commitfest - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: 2022-01 Commitfest
Date
Msg-id 20220202175656.5zacgx3ucrquvi35@jrouhaud
Whole thread Raw
In response to Re: 2022-01 Commitfest  (Jaime Casanova <jcasanov@systemguards.com.ec>)
List pgsql-hackers
On Wed, Feb 02, 2022 at 12:45:40PM -0500, Jaime Casanova wrote:
> On Thu, Feb 03, 2022 at 01:28:53AM +0800, Julien Rouhaud wrote:
> > 
> > My understanding of "Returned with Feedback" is that the patch implements
> > something wanted, but as proposed won't be accepted without a major redesign or
> > something like that.  Not patches that are going through normal "review /
> > addressing reviews" cycles.  And definitely not bug fixes either.
> > 
> > If we close all patches that had a review just because they weren't perfect in
> > their initial submission, we're just going to force everyone to re-register
> > their patch for every single commit fest.  I don't see that doing anything
> > apart from making sure that everyone stops contributing.
> > 
> 
> I had the same problem last time, "Returned with feedback" didn't feel
> fine in some cases.
> 
> After reading this i started to wish there was some kind of guide about
> this, and of course the wiki has that guide (outdated yes but something
> to start with).
> 
> https://wiki.postgresql.org/wiki/CommitFest_Checklist#Sudden_Death_Overtime
>
> This needs some love, still mentions rrreviewers for example

Yes, I looked at it but to be honest it doesn't make any sense.

It feels like this is punishing patches that get reviewed at the end of the
commitfest or that previously got an incorrect review, and somehow tries to
salvage patches from authors that don't review anything.

> but if we
> updated and put here a clear definition of the states maybe it could
> help to do CF managment.

I'm all for it, but looking at the current commit fest focusing on unresponsive
authors (e.g. close one way or another patches that have been waiting on author
for more than X days) should already help quite a lot.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Server-side base backup: why superuser, not pg_write_server_files?
Next
From: Tom Lane
Date:
Subject: Re: 2022-01 Commitfest