mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Authorship/attribution and stalled patches
Date: Sun, 1 Nov 2020 20:30:50 -0500	[thread overview]
Message-ID: <20201102013049.GR534@brightrain.aerifal.cx> (raw)
In-Reply-To: <20201102011630.GQ534@brightrain.aerifal.cx>

On Sun, Nov 01, 2020 at 08:16:32PM -0500, Rich Felker wrote:
> It came to my attention that there are a few patches in limbo where,
> after some discussion, it seems I was waiting for an updated patch
> from the contributor to apply, and it never appeared. I could and
> should just make the changes myself (this would have been more
> efficient to begin with), but I'm not sure what to do about
> authorship/attribution in that situation, and it probably deserves
> community input.
> 
> A while back, I started trying to make better use of git commit
> authorship to credit contributors, rather than just mentioning "patch
> by X" or "based on patch/idea by X" in commit messages. However I
> still don't have a clear feel for how this should work in the case
> where the patch is modified before being applied. Are there
> established norms for the degree to which a patch should be modified
> while leaving the author intact, or should it just always be converted
> to commit authorship by the person who makes the final changes, with
> original author in the description? It's really a tradeoff between
> potential misattribution of mistakes or changes the original author
> might not like, and failure to credit, and I don't know where the
> right balance is.

A further special case of this is where the content of the diff is
fine, but the commit message needs significant rewording to be
acceptable (e.g. the original only explains a what rather than a why,
or includes a why that's not the actual reason the patch is needed).

For other cases mentioned in the quoted text above, the
Co-authored-by: pseudo-header popularized by Github seems to be a
reasonable solution. But I don't feel it's appropriate to relegate
someone to a "co-author" when the entire diff (or even 99% of it) is
by them and it's just the commit message that was rewritten. (Ideally,
git's data model would have separate authorship for commit message and
diff, and I don't think existing committer field in the model is
interpreted that way.)

Rich

  reply	other threads:[~2020-11-02  1:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02  1:16 Rich Felker
2020-11-02  1:30 ` Rich Felker [this message]
2020-11-02 19:40 ` Markus Wichmann
2020-11-02 19:45   ` Rich Felker
2020-11-02 20:45     ` Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201102013049.GR534@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).