On Monday, June 23, 2025, Jelte Fennema-Nio <m...@jeltef.nl> wrote: > On Mon, 23 Jun 2025 at 18:29, Jacob Champion > <jacob.champ...@enterprisedb.com> wrote: > > Initial thoughts: > > below my reasoning (feel free to disagree). > > > - "dblink" seems overly specific compared to the others. > > It seemed roughly as specific as postgres_fdw to me. Maybe we should > make sure they are grouped more alphabetically. > > contrib/dblink > contrib/postgres_fdw > > (or in a different format like "Contrib - dblink") > > Yes, categories, and give each category its own line in the table.
> > - "Backport" seems strange. That's what the Version column is for, no? > > I still don't know how I'm supposed to use the version column (e.g. > what is the difference between stable and pg19), and it seems out of > date or not filled in half of the time. So I'd rather have it replaced > with tags with clear intent. Maybe have backport tags for each > Postgres version instead of "Backport - PG16" etc. The assumption > being, if it doesn't have a backport tag, then it should go into > master. Yeah, deprecating version at this point seems like a good choice. As for “backpatch”. I figured a single tag saying that it is needed, then have “Not” tags if any of the default version should not be updated. This is also where a user comment link attribute field explaining backpatch reasoning would be appropriate. We aren’t going to be searching and filtering on specific versions so having tags for specific versions doesn’t really make sense. The tag to distinguish between bugs and features is a key one however. > > > - "Comments Only" feels somehow... standoffish? defensive? How about > > "Comments [Requested/Needed]" or something similar? > > I meant this as "This patch changes only comments", the hover text > also explains that once selected. > Categories can help reduce this kind of confusion as well. A category for “what the patch affects” and one for “what is needed”. David J.
