public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: PG 19 release notes and authors
Date: Sat, 4 Apr 2026 22:12:57 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2-WzmNPpvDc9EO9fvDJUnmE_ppZWwwwfxRBk7nybjEL8Y1=A@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAH2-WzmNPpvDc9EO9fvDJUnmE_ppZWwwwfxRBk7nybjEL8Y1=A@mail.gmail.com>
On Sat, Apr 4, 2026 at 10:02:40PM -0400, Peter Geoghegan wrote:
> On Sat, Apr 4, 2026 at 7:27 PM Bruce Momjian <[email protected]> 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 <[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]
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