Re: 2022-01 Commitfest

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: Greg Stark <stark(at)mit(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: 2022-01 Commitfest
Date: 2022-02-02 17:56:56
Message-ID: 20220202175656.5zacgx3ucrquvi35@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-02-02 18:00:18 Re: 2022-01 Commitfest
Previous Message Tom Lane 2022-02-02 17:55:52 Re: Server-side base backup: why superuser, not pg_write_server_files?