PG 19 release notes and authors

On Sunday, April 5, 2026, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> On 2026-Apr-05, Bruce Momjian wrote:
>
> > I just updated the wiki to handle this case because obviously
> > Co-authored-by is listing more than just committers:
> >
> > https://wiki.postgresql.org/wiki/Commit_Message_Guidance#Ta
> gs%3A_%22%3A%22
> > Used to indicate the patch authors. "Co-authored-by:" should list
> > individuals who modified the patch but should not be listed as
> > authors in the release notes.
>
> I don't see in what way this is useful. Why do you want to suppress
> people from getting credit for the work they do? Having changed the
> commit guidance this way, I think no committer would use Co-authored-by
> at all.

The ambiguity is whether the committer is an author. We can either say
committers are not/never implicitly authors so if the committer needs to be
made the/an author they add themselves using an author or co-author line.
Or we let them be implicitly an author if there is no actual author
credited. In which case co-author lines are needed because the author line
cannot be used. Regardless, a co-author is always an author - it’s in the
title - and should be listed any place authorship is listed. The existing
guidance for Author is implicit for the committer. If there is a real
author noted the committer is not automatically an author. Whether we’ve
used author+co-author or multiple author lines is immaterial, they
communicate the same basic thing (committer is not an author, and there are
more than one author), at a high level, today. Maybe in the future we’d
try to distinguish them in practice, but that hasn’t happened in any way
that matters today.

No author, no co-author: committer is sole author
Author+(author and/or co-author)s: committer is not an author, all others
are
Only co-authors: committer is author, as are the co-author(s)

> > I am not sure PG 19 follows this, but we might want to follow it going
> > forward.
>
> More and more I am getting the feeling that the commit guidance is
> actually misguided. The document itself is not very good (I mean, why
> use XML-lookalike to represent a commit message, which is regular
> English prose??); and I don't feel it represents actual consensus.
>
> > A larger issue is that since we now have links to the commits in the
> > release notes, there might no longer be a need to list _any_ names next
> > to the release note items.
>
> I don't understand your motivation for saying things like these.
>

I was under the impression this aspect of producing the release notes is
scripted, in which case I do think it is valuable enough to continue
doing. I do think we have enough structured data that if we felt our
attribution efforts were insufficient there are more things we could do.
I’m not sure this is the most valuable way to expose this data but it’s a
way, we likely don’t do enough promotion even with it, and it seems low
maintenance. But maybe there is a cost/benefit discussion to be had here.

David J.