public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Peter Geoghegan <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: PG 19 release notes and authors
Date: Mon, 6 Apr 2026 09:57:49 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwY8Fm_JdXQUvEX5KGXbfLh3onZeFj9ZPEL9aB88wT7aQA@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAKFQuwY8Fm_JdXQUvEX5KGXbfLh3onZeFj9ZPEL9aB88wT7aQA@mail.gmail.com>
On Sun, Apr 5, 2026 at 07:47:35AM -0700, David G. Johnston wrote:
> On Sunday, April 5, 2026, Álvaro Herrera <[email protected]> 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 <[email protected]>
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 <[email protected]>
Reviewed-by: Pavel Seleznev <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CAKK5BkHixcivSCA9pfd_eUp7wkLRhvQ6OtGLAYrWC%3Dk7E76LDQ%40m...
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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
view thread (53+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: PG 19 release notes and authors
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox