Re: PG 18 relnotes and RC1 - Mailing list pgsql-hackers

On Thu, Sep 18, 2025 at 2:19 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> Glad to hear I've been doing my job backwards for years ;) That said, I
> am always willing to learn how to improve the process.

I don't really care for the flip tone here. I do think there's a
problem here, and I do think it's longstanding. I think it predates
your involvement, but whether it does or not I'd like to fix it.
That's not an accusation that you're doing anything backwards or not,
it's just the facts as I see them.

> > Why for example should we  drop
> > mentioning the ability to return OLD.* and NEW.* in favor of mentioned
> > UUIDv7?
>
> UUIDv7 was in the original one, and it's been carried forward. The
> change was I explicitly brought in the function name and the link to it.

You're right. That's my mistake.

> I posted a patch now; there's still a few days before this is finalized,
> and we can iterate on it. The press release was also posted a few weeks
> back with time for people to comment on it, too.
>
> This is a task I've helped on every year for nearly a decade and there
> have been limited complaints, other than a healthy discussion on what
> features should be in the list. For personal reasons I didn't get to
> this specific part as early as usual, and given my history of the work
> I've done on the release, I would have expected a bit more empathy
> towards pulling this together. And of course, I'm always open to
> well-stated opinions on what to do.

I am very grateful for all of the work that everyone does to make
releases happen, and I very much appreciate being able to work on a
piece of software that is as great as PostgreSQL without always having
to sweat all the details of getting it out the door. Nevertheless, I
think the problem of the major features list being chronically late is
a longstanding one, and I think we should try to find a way to fix it.

There was one year that Bruce wasn't able to write the release notes
when the community wanted them due to other time commitments and he
disclosed that. We then discussed whether to go with having him do
them at a later time or have someone else do them, and chose the
latter option. I ended up doing them that year. I'm grateful that I
haven't had to do that again because it was a lot of work, but I'm
ALSO grateful that Bruce was upfront about the problem and willing to
cede the responsibility to someone who had more time available during
the critical window. If whatever prevented Bruce from doing the
release notes at the usual time was something deserving of sympathy,
then my sympathy was his for the asking, as is yours. But that is
really a personal conversation that in my view shouldn't have much to
do with how the project assigns tasks. If for example a committer has
a personal issue come up right before feature freeze, we may on a
personal level have a lot of sympathy for them if the result is that
their big feature misses the release, but we have yet to grant a
feature freeze exemption to someone on the basis of something like
that happening, and I don't think we should.

As I see it, while our feature freeze isn't perfect -- mostly because
too many things get slipped in at the last minute that aren't really
in great shape -- it's a lot better than the old process where nobody
really knew what the deadline was. Similarly here, we should just
agree on some deadline for when the PR and major feature tasks should
get completed; and if you or whoever don't think you're going to be
able to make those timelines, then we can either decide on someone
else to do it or we can decide to move the deadline. Either way, if we
do that, we're operating by consensus and a shared set of
expectations.

--
Robert Haas
EDB: http://www.enterprisedb.com