Re: PG 19 release notes and authors - Mailing list pgsql-hackers

On Sun, Apr  5, 2026 at 07:47:35AM -0700, David G. Johnston wrote:
> On Sunday, April 5, 2026, Álvaro Herrera <alvherre@kurilemu.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

Yes, if their is no author/co-author, the committer is assumed to be the
author.

> 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)

Wow, I never thought that was a valid pattern, but I see a few PG 19
commit messages using that, e.g.:

    Author: Peter Eisentraut <peter@eisentraut.org>
    2025-08-12 [5f19d13df] libpq: Set LDAP protocol version 3
    
        libpq: Set LDAP protocol version 3
    
        Some LDAP servers reject the default version 2 protocol.  So set
        version 3 before starting the connection.  This matches how the
        backend LDAP code has worked all along.
    
        Co-authored-by: Andrew Jackson <andrewjackson947@gmail.com>
        Reviewed-by: Pavel Seleznev <pavel.seleznev@gmail.com>
        Discussion:
https://www.postgresql.org/message-id/flat/CAKK5BkHixcivSCA9pfd_eUp7wkLRhvQ6OtGLAYrWC%3Dk7E76LDQ%40mail.gmail.com

Is that what people are using?  A missing Author, and co-authors means
the committer is the author?  Right?  Shouldn't we document this?  That
does give a unique use for Co-authored-by.

>     > 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

The adding of the links is automated.

> 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.

I guess that is my question.  I don't think the author names have the
same practical value now that we have commit links, but if people think
it still has _sufficient_ value, we should keep it --- that was my
question.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.