From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26350 invoked from network); 2 Nov 2020 19:46:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Nov 2020 19:46:12 -0000 Received: (qmail 30662 invoked by uid 550); 2 Nov 2020 19:46:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30644 invoked from network); 2 Nov 2020 19:46:10 -0000 Date: Mon, 2 Nov 2020 14:45:58 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20201102194557.GU534@brightrain.aerifal.cx> References: <20201102011630.GQ534@brightrain.aerifal.cx> <20201102194028.GA2009@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201102194028.GA2009@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Authorship/attribution and stalled patches 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