* [musl] Authorship/attribution and stalled patches @ 2020-11-02 1:16 Rich Felker 2020-11-02 1:30 ` Rich Felker 2020-11-02 19:40 ` Markus Wichmann 0 siblings, 2 replies; 5+ messages in thread From: Rich Felker @ 2020-11-02 1:16 UTC (permalink / raw) To: musl 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. Rich ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] Authorship/attribution and stalled patches 2020-11-02 1:16 [musl] Authorship/attribution and stalled patches Rich Felker @ 2020-11-02 1:30 ` Rich Felker 2020-11-02 19:40 ` Markus Wichmann 1 sibling, 0 replies; 5+ messages in thread From: Rich Felker @ 2020-11-02 1:30 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] Authorship/attribution and stalled patches 2020-11-02 1:16 [musl] Authorship/attribution and stalled patches Rich Felker 2020-11-02 1:30 ` Rich Felker @ 2020-11-02 19:40 ` Markus Wichmann 2020-11-02 19:45 ` Rich Felker 1 sibling, 1 reply; 5+ messages in thread From: Markus Wichmann @ 2020-11-02 19:40 UTC (permalink / raw) To: musl 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. > > Rich Why not just apply the patch as-is (leaving the patch author as committer), then commit the necessary changes afterwards (as yourself)? That way the original patch becomes its own commit, and we can see what had to be changed afterwards. If you want to make it extraordinarily clean, you could do all of that on a branch and merge the product afterwards. Seems to be the cleanest solution. If the patch is not yet in a form where the fixes are obvious (e.g. the reallocarray() patch we had a while back that either would give you horrible performance or copies of sensitive data lying around in address space), then the patch is probably not ripe, anyway. Ciao, Markus ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] Authorship/attribution and stalled patches 2020-11-02 19:40 ` Markus Wichmann @ 2020-11-02 19:45 ` Rich Felker 2020-11-02 20:45 ` Wolf 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2020-11-02 19:45 UTC (permalink / raw) To: musl On Mon, Nov 02, 2020 at 08:40:28PM +0100, Markus Wichmann wrote: > 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. > > > > Rich > > Why not just apply the patch as-is (leaving the patch author as > committer), then commit the necessary changes afterwards (as yourself)? > That way the original patch becomes its own commit, and we can see what > had to be changed afterwards. If you want to make it extraordinarily > clean, you could do all of that on a branch and merge the product > afterwards. Seems to be the cleanest solution. If the patch is not yet > in a form where the fixes are obvious (e.g. the reallocarray() patch we > had a while back that either would give you horrible performance or > copies of sensitive data lying around in address space), then the patch > is probably not ripe, anyway. This would be a major regression in maintainership quality. It introduces versions that don't work/have new bugs that would not otherwise be in the history, making it harder to bisect, harder for patches to commute (and be backported etc.), harder to read and understand, etc. The intent of the history is to be a history is approved changes, with clearly documented motivations for each. Rich ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] Authorship/attribution and stalled patches 2020-11-02 19:45 ` Rich Felker @ 2020-11-02 20:45 ` Wolf 0 siblings, 0 replies; 5+ messages in thread From: Wolf @ 2020-11-02 20:45 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1191 bytes --] Hello, On 2020-11-02 14:45:58 -0500, Rich Felker wrote: > This would be a major regression in maintainership quality. It > introduces versions that don't work/have new bugs that would not > otherwise be in the history, making it harder to bisect, harder for > patches to commute (and be backported etc.), harder to read and > understand, etc. The intent of the history is to be a history is > approved changes, with clearly documented motivations for each. My opinion on this is that for 1. Commit message only changes Just rewrite the commit message and add note at the bottom along the lines that "Commit message by Rich" or something like that. And leave original author. 2. Changes in the patch itself This I think calls for common sense approach, based on how large the changes are. Same approach in as 1., in case of small changes add something like "Slightly modified by Rich", in case of large(r) rewrite "Based on patch by AUTHOR". If the end goal is to merge those stale patches, I think this is best that can be done. W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-02 20:46 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-02 1:16 [musl] Authorship/attribution and stalled patches Rich Felker 2020-11-02 1:30 ` Rich Felker 2020-11-02 19:40 ` Markus Wichmann 2020-11-02 19:45 ` Rich Felker 2020-11-02 20:45 ` Wolf
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).