Re: [Commitfest 2022-07] Patch Triage: Waiting on Author - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: [Commitfest 2022-07] Patch Triage: Waiting on Author
Date
Msg-id 20220801155105.GG15006@telsasoft.com
Whole thread Raw
In response to Re: [Commitfest 2022-07] Patch Triage: Waiting on Author  (Jacob Champion <jchampion@timescale.com>)
List pgsql-hackers
On Thu, Jul 28, 2022 at 08:58:31AM -0700, Jacob Champion wrote:
> On Thu, Jul 28, 2022 at 4:46 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> > Daniil is working on this, but currently he's on vacation.
> > I think we should not mark patch as RwF and move it to next CF instead.
> 
> Is there a downside to marking it RwF, from your perspective? As
> Robert pointed out upthread, it can be switched back at any time once
> Daniil's ready.

As someone interested in seeing the patch progress, I still think it may be
better to close the patch record, which can be re-opened when it's ready to be
reviewed.

> They take up reviewer time and need to be triaged continually.

Alternately:

@Jacob: Is there any reason why it's necessary to do anything at all ?
Does something bad happen if the patches are left in the current CF ?
Why make not let patch authors (re) submit the patch for review when they're
ready?  Someone went to the effort to move it to the current CF, even though the
patch wasn't ready to be reviewed.  It'd be less work and avoid the process of
"moving patches to the next CF" even though (at least in this case) it maybe
shouldn't have even been in the current CF.

Also, is there a place which lists all of an author's patches (current and
historic)?  I think people would be less adverse to having their patches closed
if 1) they knew they could re-open them; and, 2) there were a list of patches
and their disposition (not a separate list per commitfest, and not showing each
patch duplicated for each CF that a patch was opened in).

-- 
Justin



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: [Commitfest 2022-07] is Done!
Next
From: Simon Riggs
Date:
Subject: Re: Dump/Restore of non-default PKs