PG 19 release notes and authors
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.
--
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.
On Sat, 4 Apr 2026 at 16:50, Bruce Momjian <bruce@momjian.us> wrote:
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.
If it's not the "Co-authored-by" tag, how else would a project of a
non-committer cooperating with a committer be tagged?
Publicly, the guidance for commit tag usage seems to be [0]https://wiki.postgresql.org/wiki/Commit_Message_Guidance
"Co-authored-by:" is used by committers when they want to give
full credit to the named individuals, but also indicate that they
made significant changes.
Removing that committer's "full credit to the named individuals" seems
out of place to me.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
[0]: https://wiki.postgresql.org/wiki/Commit_Message_Guidance
On 4 Apr 2026, at 17:06, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
Publicly, the guidance for commit tag usage seems to be [0]
"Co-authored-by:" is used by committers when they want to give
full credit to the named individuals, but also indicate that they
made significant changes.Removing that committer's "full credit to the named individuals" seems
out of place to me.
Agreed, as a committer I want the persons listed as co-author in the git log to
be credited in the release notes.
--
Daniel Gustafsson
On 4 Apr 2026, at 19:50, Bruce Momjian <bruce@momjian.us> wrote:
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.
Speaking of co-authors - I think they absolutely should be included in the
release notes credits.
The more recognition we give contributors, the more motivation newcomers
have to join the development community. There are edge cases where a feature
gets reverted in a later minor release, but those are rare. What matters
is that we need a steady stream of new contributors, and crediting everyone's
work - including co-authors - is one of the most effective ways to
encourage that.
Best regards, Andrey Borodin.
On Sat, Apr 4, 2026 at 11:19 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
On 4 Apr 2026, at 19:50, Bruce Momjian <bruce@momjian.us> wrote:
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.Speaking of co-authors - I think they absolutely should be included in the
release notes credits.The more recognition we give contributors, the more motivation newcomers
have to join the development community. There are edge cases where a
feature
gets reverted in a later minor release, but those are rare. What matters
is that we need a steady stream of new contributors, and crediting
everyone's
work - including co-authors - is one of the most effective ways to
encourage that.
+1, and additionally encourages collaboration among contributors.
Thanks,
Satya
On 04.04.26 17:06, Matthias van de Meent wrote:
On Sat, 4 Apr 2026 at 16:50, Bruce Momjian <bruce@momjian.us> wrote:
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.If it's not the "Co-authored-by" tag, how else would a project of a
non-committer cooperating with a committer be tagged?
Two Author tags.
Hi,
On April 4, 2026 5:56:01 PM EDT, Peter Eisentraut <peter@eisentraut.org> wrote:
On 04.04.26 17:06, Matthias van de Meent wrote:
On Sat, 4 Apr 2026 at 16:50, Bruce Momjian <bruce@momjian.us> wrote:
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.If it's not the "Co-authored-by" tag, how else would a project of a
non-committer cooperating with a committer be tagged?Two Author tags.
That's not how I understood its use so far, and I'm surely not alone in that. We could rephrase this in the wiki page, but we can't go back and edit the commit messages...
Greetings,
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, Apr 4, 2026 at 11:18:33PM +0500, Andrey Borodin wrote:
On 4 Apr 2026, at 19:50, Bruce Momjian <bruce@momjian.us> wrote:
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.Speaking of co-authors - I think they absolutely should be included in the
release notes credits.The more recognition we give contributors, the more motivation newcomers
have to join the development community. There are edge cases where a feature
gets reverted in a later minor release, but those are rare. What matters
is that we need a steady stream of new contributors, and crediting everyone's
work - including co-authors - is one of the most effective ways to
encourage that.
This is the same argument we have had for ages, accuracy vs
encouragement.
--
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.
On Sat, Apr 4, 2026 at 06:16:10PM -0400, Andres Freund wrote:
Hi,
On April 4, 2026 5:56:01 PM EDT, Peter Eisentraut <peter@eisentraut.org> wrote:
On 04.04.26 17:06, Matthias van de Meent wrote:
On Sat, 4 Apr 2026 at 16:50, Bruce Momjian <bruce@momjian.us> wrote:
In the PG 19 commits, I am seeing several commits with Author and
Co-authored-by tags. FYI, I think we agreed that only the Author names
are mentioned as the authors in the release notes.If it's not the "Co-authored-by" tag, how else would a project of a
non-committer cooperating with a committer be tagged?Two Author tags.
That's not how I understood its use so far, and I'm surely not alone in that. We could rephrase this in the wiki page, but we can't go back and edit the commit messages...
The wiki page says:
https://wiki.postgresql.org/wiki/Commit_Message_Guidance
Author:
Co-authored-by:
Used to indicate the patch authors. "Co-authored-by:" is used by
committers when they want to give full credit to the named individuals,
but also indicate that they made significant changes.
but I am seeing many cases where there is an Author tag, who is not the
committer, and also Co-authored-by tags in the same message. That does
not follow the wiki text.
I need to know what to do for PG 19, and what to do for later major
releases. I think Peter's point is why are people using Author and
Co-authored-by in the same commits, and not just two Authors.
I thought we had this resolved but looking at the PG 19 commits,
obviously not.
To clarify, I assume Co-authored-by would appear in the Acknowledgments
section at the bottom of the major release notes, e.g.:
https://www.postgresql.org/docs/current/release-18.html#RELEASE-18-ACKNOWLEDGEMENTS
--
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.
On Sat, Apr 4, 2026 at 7:27 PM Bruce Momjian <bruce@momjian.us> wrote:
This is the same argument we have had for ages, accuracy vs
encouragement.
If that is the new policy, my policy will be to never use the
Co-authored-by tag, except perhaps for my own name. If I don't think
someone deserves authorship credit, then I just won't list them as an
author in the commit message.
Given how the tag is apparently being interpreted, the only scenario
where it still seems useful to me personally is one where I make
substantial revisions to a patch but, for whatever reason,
specifically do not think I deserve a full authorship credit. Which,
to be fair, doesn't seem too implausible. The need for substantial
revisions isn't an inherently good indicator of whether the original
patch author deserves authorship credit in the release notes.
Performing such revisions probably shouldn't be automatic grounds for
committers to receive a release notes credit.
In such a scenario, where I list myself using the Co-authored-by tag,
the tag is useful because it avoids a weird mixed signal. It would be
strange not to acknowledge that I technically wrote much of the code
in the committed patch; what if my code had a bug that the original
code didn't? At the same time, the tag avoids giving me more credit
than I deserve, which is what I'd want to happen when I choose to use
the tag (I'd want that out of a sense of fairness).
What I'm saying here boils down to this: I don't think it's sensible
to expect the use of a specific tag variant (or even the order in
which author names appear) to convey much useful information. I really
hope nobody reads too much into my choices in this area.
--
Peter Geoghegan
On Sat, Apr 4, 2026 at 10:02:40PM -0400, Peter Geoghegan wrote:
On Sat, Apr 4, 2026 at 7:27 PM Bruce Momjian <bruce@momjian.us> wrote:
This is the same argument we have had for ages, accuracy vs
encouragement.If that is the new policy, my policy will be to never use the
Co-authored-by tag, except perhaps for my own name. If I don't think
someone deserves authorship credit, then I just won't list them as an
author in the commit message.Given how the tag is apparently being interpreted, the only scenario
where it still seems useful to me personally is one where I make
substantial revisions to a patch but, for whatever reason,
specifically do not think I deserve a full authorship credit. Which,
to be fair, doesn't seem too implausible. The need for substantial
revisions isn't an inherently good indicator of whether the original
patch author deserves authorship credit in the release notes.
Performing such revisions probably shouldn't be automatic grounds for
committers to receive a release notes credit.In such a scenario, where I list myself using the Co-authored-by tag,
the tag is useful because it avoids a weird mixed signal. It would be
strange not to acknowledge that I technically wrote much of the code
in the committed patch; what if my code had a bug that the original
code didn't? At the same time, the tag avoids giving me more credit
than I deserve, which is what I'd want to happen when I choose to use
the tag (I'd want that out of a sense of fairness).
Yes, that was the original purpose. Basically, if a commit has no
"Author" tag, the committer is assumed to be the author. If there is an
"Author" tag, the committer is not assumed to be the author. If there
is an Author tag and the committer wants author credit, they must add
their name as an author. If the committer wants to indicate they
changed the patch, and potentially added bugs, but doesn't want credit,
the wiki says to use Co-authored-by.
What I'm saying here boils down to this: I don't think it's sensible
to expect the use of a specific tag variant (or even the order in
which author names appear) to convey much useful information. I really
hope nobody reads too much into my choices in this area.
Well, I don't care what we decide, but we should decide something. You
can say they don't convey information, but I need to put something in
the release notes, so they are forced to have some effect.
What confuses me are cases where Authors are not the committer and
Co-authored-by are not the committer. This combination is not
documented in the wiki, which makes me think people are using
Co-authored-by in ways that are inconsistent or I don't understand.
--
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.
On Sat, Apr 4, 2026 at 10:13 PM Bruce Momjian <bruce@momjian.us> wrote:
Yes, that was the original purpose.
I didn't actually know that. That's likely my own fault. (OTOH I
haven't actually used the new tag at all, at least not yet.)
Basically, if a commit has no
"Author" tag, the committer is assumed to be the author. If there is an
"Author" tag, the committer is not assumed to be the author. If there
is an Author tag and the committer wants author credit, they must add
their name as an author. If the committer wants to indicate they
changed the patch, and potentially added bugs, but doesn't want credit,
the wiki says to use Co-authored-by.
Got it. That makes sense to me (obviously, since I already said that
that's the only policy that could possibly be useful).
What I'm saying here boils down to this: I don't think it's sensible
to expect the use of a specific tag variant (or even the order in
which author names appear) to convey much useful information. I really
hope nobody reads too much into my choices in this area.Well, I don't care what we decide, but we should decide something. You
can say they don't convey information, but I need to put something in
the release notes, so they are forced to have some effect.
I think that Co-authored-by should either: 1. have a specific
mechanical purpose (like affecting how the release notes are written),
OR 2. not exist at all.
What's the point, otherwise? It just doesn't make sense to have a
Co-authored-by that merely conveys a general vibe. These things are
inherently squishy and subjective. Pretending otherwise would be a
mistake (to be clear I'm not suggesting that you or anybody else has
made that mistake).
--
Peter Geoghegan
On Sat, Apr 4, 2026 at 10:29:15PM -0400, Peter Geoghegan wrote:
On Sat, Apr 4, 2026 at 10:13 PM Bruce Momjian <bruce@momjian.us> wrote:
Yes, that was the original purpose.
I didn't actually know that. That's likely my own fault. (OTOH I
haven't actually used the new tag at all, at least not yet.)
Yes, that is what I used it for in the past.
Basically, if a commit has no
"Author" tag, the committer is assumed to be the author. If there is an
"Author" tag, the committer is not assumed to be the author. If there
is an Author tag and the committer wants author credit, they must add
their name as an author. If the committer wants to indicate they
changed the patch, and potentially added bugs, but doesn't want credit,
the wiki says to use Co-authored-by.Got it. That makes sense to me (obviously, since I already said that
that's the only policy that could possibly be useful).What I'm saying here boils down to this: I don't think it's sensible
to expect the use of a specific tag variant (or even the order in
which author names appear) to convey much useful information. I really
hope nobody reads too much into my choices in this area.Well, I don't care what we decide, but we should decide something. You
can say they don't convey information, but I need to put something in
the release notes, so they are forced to have some effect.I think that Co-authored-by should either: 1. have a specific
mechanical purpose (like affecting how the release notes are written),
OR 2. not exist at all.What's the point, otherwise? It just doesn't make sense to have a
Co-authored-by that merely conveys a general vibe. These things are
inherently squishy and subjective. Pretending otherwise would be a
mistake (to be clear I'm not suggesting that you or anybody else has
made that mistake).
Yes, that was the argument --- Co-authored-by should have some purpose
because making it behave like Author has little value.
--
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.
On Sat, Apr 4, 2026 at 10:12:57PM -0400, Bruce Momjian wrote:
What confuses me are cases where Authors are not the committer and
Co-authored-by are not the committer. This combination is not
documented in the wiki, which makes me think people are using
Co-authored-by in ways that are inconsistent or I don't understand.
I now realize I was treating non-committers listed as Co-authored-by the
same as committers being listed. Someone who is listed as
Co-authored-by made changes to the patch, perhaps adding bugs, but not
someone who should be listed as an author of the release note item.
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#Tags%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 am not sure PG 19 follows this, but we might want to follow it going
forward.
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.
--
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.
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#Tags%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.
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.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Subversion to GIT: the shortest path to happiness I've ever heard of
(Alexey Klyukin)
On 5 Apr 2026, at 15:47, Bruce Momjian <bruce@momjian.us> wrote:
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.
If we have to discuss on this list abut whom should be credited and who
shouldn't, then it seems a tall order to expect the average reader to have it
figured out.
I think we should continue with the tradition of listing authors.
--
Daniel Gustafsson
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: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.
On 4/5/26 10:39, Daniel Gustafsson wrote:
On 5 Apr 2026, at 15:47, Bruce Momjian <bruce@momjian.us> wrote:
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.If we have to discuss on this list abut whom should be credited and who
shouldn't, then it seems a tall order to expect the average reader to have it
figured out.I think we should continue with the tradition of listing authors.
+1
--
Joe Conway
PostgreSQL Contributors Team
Amazon Web Services: https://aws.amazon.com
Hi,
On 2026-04-05 16:09:57 +0200, Álvaro Herrera 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#Tags%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 think that is a completely unwarranted change for which there is zero
concensus.
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.
+1
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.
I think a more useful format would be something that can sensibly get used as
a git commit template (mine has tags I commonly use that I just delete when
not used).
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.
+1
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
On 2026-04-05 16:09:57 +0200, Álvaro Herrera 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:
I think that is a completely unwarranted change for which there is zero
concensus.
Indeed. You exceeded your authority here.
Even if there were consensus about making this change going forward,
the existing commit records were made under a different understanding.
You can't just say you're going to reinterpret them in a way that
excludes giving credit where credit is due.
regards, tom lane
