Re: Question about criteria for adding items to the v19 open items wiki page - Mailing list pgsql-hackers

From Chao Li
Subject Re: Question about criteria for adding items to the v19 open items wiki page
Date
Msg-id 7A56B9A1-DC86-41BF-B171-7E6D68902CDA@gmail.com
Whole thread
In response to Re: Question about criteria for adding items to the v19 open items wiki page  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Question about criteria for adding items to the v19 open items wiki page
List pgsql-hackers

> On Apr 23, 2026, at 12:57, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Wednesday, April 22, 2026, Chao Li <li.evan.chao@gmail.com> wrote:
> Please forgive this probably naive question, as this is the first release cycle I’ve experienced.
>
> I’ve seen people mention putting something on the v19 open items wiki page many times, but I’m not sure what kinds of
thingsare supposed to go there. What should be added there, and are there any criteria for deciding that? 
>
> Any bugs discovered in newly developed features in v19.  As a practical matter, ones that seem complicated to resolve
makeit there since quickly resolved ones just get fixed. 
>
> Bugs that reproduce in v18 or earlier would not be placed there.
>
> It’s a chance to demonstrate personal judgement.  Severity and committer/author responsiveness are two additional
criteriato judge.  It’s both a simple tracker but also a kind of escalation channel since it gets RMT members involved. 
>
> David J.
>

In the Open Issues section, I see the first item has no owner listed, so I assume we should add new items to the top of
thelist, and then, once they are confirmed, either an owner will be assigned, or the item will be moved to “Won’t Fix”
orremoved. Is that right? 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Fix memory leak in postmasterMain
Next
From: David Rowley
Date:
Subject: Re: [PATCH] Fix hashed ScalarArrayOp semantics for NULL LHS with non-strict comparators