Обсуждение: thoughts on v18 RMT
The v18 RMT [0] just had -- fingers crossed -- its last regular meeting.
Overall, things went smoothly, and it didn't require an enormous amount of
time, so I'd gladly volunteer for the v19 RMT. However, I still wanted to
jot down a few things while they are fresh in my mind:
* We met bi-weekly over video chat for a half hour and primarily discussed
the current set of open items [1]. It was uncommon to use the entire 30
minutes, but on the whole, this felt like a good frequency. If there was
some sort of crisis, we probably would've met more often.
* Hackers were responsive to communication from the RMT, so minimal nagging
was required. In a couple of cases, the RMT even helped solicit reviewers
for patches, and folks gladly stepped in to help. I was quite pleased with
the level of cooperation. For the most part, we were able to let the
regular community process take the lead.
* Despite the recommendation in the RMT wiki page [0], we did not
communicate with pgsql-release@ as much as we probably should have. One
specific thing that I'd advise future RMTs to do is to try to establish (or
pester pgsql-release@ to establish) the release dates a bit sooner so that
hackers have deadlines to work against. IMHO the informality and
flexibility of the process is nice, but some extra communication might help
prevent uncertainty.
* 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.
I've CC'd Tomas and Heikki here in case there is anything they want to add
or disagree with. Thanks everyone!
[0] https://wiki.postgresql.org/wiki/Release_Management_Team
[1] https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
[2] http://postgr.es/c/b585f25
[3] http://postgr.es/c/142885d
[4] https://postgr.es/m/aMxeVgDW_0pfUBhi%40nathan
--
nathan
> On 23 Sep 2025, at 19:03, Nathan Bossart <nathandbossart@gmail.com> wrote: > I've CC'd Tomas and Heikki here in case there is anything they want to add > or disagree with. Thanks everyone! And a big Thank you! to the three of you for taking on this important work. -- Daniel Gustafsson
* 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.