Re: Credits For v19

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Credits For v19
Date: 2026-08-28 20:58:39
Message-ID: CADkLM=ey07s-pX4WHUwurT_-y09ukTfDCDC7qkc3mWU=jPuRtg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 28, 2026 at 4:11 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > On 28 Aug 2026, at 20:53, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>
> > While commits are still coming in that would fit the v19 window, it may
> be
> > easier for the committer to manually scan those commits against the
> existing
> > list (whichever they choose to use) than wait for me to re-generate the
> list,
> > though I'm happy to do so if requested.
>
>
> It seems like a safer approach to regenerate the data based on the commits
> which have happened since you ran the report last.

I've got nothing against continuing to re-run the process (it's an ETL,
really) periodically as we get closer to release date. It runs fairly fast
across the timeline in question (REL_18_STABLE..REL_19_STABLE). The issue
was more with the clutter of re-posting lists that haven't changed much if
at all. Would a once-a-week cadence make sense? I'll include an
as-of-commit-hash freshness date on each one.

As a side note, what I've written doesn't really work incrementally. It
scans the commits for "perfect" tags, then uses those as a basis for
sorting out the proper attribution for less well-formed tags, and names
that weren't in tags at all, regardless of whether those proper tags
happened before or after the ambiguous one. So it's possible for an old
commit to "learn" from a new one, hence just re-running the whole thing.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-08-28 21:05:18 Re: Error handling in after-startup shmem requests
Previous Message Gustavo William 2026-08-28 20:43:44 Re: enhancing pg_basebackup speeds up to ~23Gbps (small fixes + io_uring/Direct I/O)