From: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
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:45:40 |
Message-ID: | YfrDRHq/kmiiMj2k@ahch-to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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, but if we
updated and put here a clear definition of the states maybe it could
help to do CF managment.
--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-02 17:55:52 | Re: Server-side base backup: why superuser, not pg_write_server_files? |
Previous Message | Julien Rouhaud | 2022-02-02 17:28:53 | Re: 2022-01 Commitfest |