Re: thoughts on v18 RMT

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, tomas(at)vondra(dot)me, hlinnaka(at)iki(dot)fi
Subject: Re: thoughts on v18 RMT
Date: 2025-09-24 20:36:45
Message-ID: CADkLM=cy1ccOgY78swYf2bZx6=9nSEb6fzdVtoV2c-BszNamFg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> * The lists of major features [2] and acknowledgments [3] were done
> last-minute and weren't tracked by the RMT. As proposed elsewhere [4], I
> think we should set a deadline of beta{2,3} for these and have the RMT
> track them as open items. That means we'll also need to find volunteers
> rather early in the process, perhaps around pgconf.dev time.
>

As for the acknowledgements, I took this over knowing it was a fairly
informal process that could use some automation, but ultimately still
needed manual review. At the time, it seemed obvious that the list of
credits was initially quite simple and small, but had grown beyond the
existing process, so something was needed to automate as much as possible,
and if possible reduce the workload for whatever manual review remained.

I've created some scripts that try to capture as many attributions and
mentions as possible, first by consulting lists of known past contributors
and then by common regex patterns. But it also "redacts" that same
information from the git log output, making it easier to manually review,
as the viewer need only concern themselves with the text that hasn't
already generated names or known non-names. This was a process that
required many refinements over many iterations, and more refinements are
yet to come.

The biggest outputs of all this work are the growing list of name+email
pairs of known past contributors, plus the preferred spellings of those
names. Searching for known names/emails is far less error prone than
regexes, obviously, so that will automatically get better future
iterations, and will in turn reduce the amount of manual review that will
always need to be done, reducing that process to handling names we haven't
previously encountered before.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2025-09-24 21:22:05 Re: GNU/Hurd portability patches
Previous Message Joel Jacobson 2025-09-24 20:34:49 Re: Optimize LISTEN/NOTIFY