From: Vlastimil Babka <vbabka@suse.cz> To: "ksummit-discuss@lists.linuxfoundation.org" <ksummit-discuss@lists.linuxfoundation.org> Cc: LKML <linux-kernel@vger.kernel.org> Subject: [Ksummit-discuss] crediting bug reports and fixes folded into original patch Date: Thu, 3 Dec 2020 00:43:52 +0100 [thread overview] Message-ID: <ea32eb02-5e44-0469-772b-34b5cb882543@suse.cz> (raw) Hi, there was a bit of debate on Twitter about this, so I thought I would bring it here. Imagine a scenario where patch sits as a commit in -next and there's a bug report or fix, possibly by a bot or with some static analysis. The maintainer decides to fold it into the original patch, which makes sense for e.g. bisectability. But there seem to be no clear rules about attribution in this case, which looks like there should be, probably in Documentation/maintainer/modifying-patches.rst The original bug fix might include a From: $author, a Reported-by: (e.g. syzbot), Fixes: $next-commit, some tag such as Addresses-Coverity: to credit the static analysis tool, and an SoB. After folding, all that's left might be a line as "include fix from $author" in the SoB area. This is a loss of metadata/attribution just due to folding, and might make contributors unhappy. Had they sent the fix after the original commit was mainline and immutable, all the info above would "survive" in the form of new commit. So I think we could decide what the proper format would be, and document it properly. I personally wouldn't mind just copy/pasting the whole commit message of the fix (with just a short issue description, no need to include stacktraces etc if the fix is folded), we could just standardize where, and how to delimit it from the main commit message. If it's a report (person or bot) of a bug that the main author then fixed, preserve the Reported-by in the same way (making clear it's not a Reported-By for the "main thing" addressed by the commit). In the debate one less verbose alternatve proposed was a SoB with comment describing it's for a fix and not whole patch, as some see SoB as the main mark of contribution, that can be easily found and counted etc. I'm not so sure about it myself, as AFAIK SoB is mainly a DCO thing, and for a maintainer it means something else ("passed through my tree") than for a patch author. And this approach would still lose the other tags. Thoughts? Vlastimil _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz> To: "ksummit-discuss@lists.linuxfoundation.org" <ksummit-discuss@lists.linuxfoundation.org> Cc: LKML <linux-kernel@vger.kernel.org> Subject: crediting bug reports and fixes folded into original patch Date: Thu, 3 Dec 2020 00:43:52 +0100 [thread overview] Message-ID: <ea32eb02-5e44-0469-772b-34b5cb882543@suse.cz> (raw) Hi, there was a bit of debate on Twitter about this, so I thought I would bring it here. Imagine a scenario where patch sits as a commit in -next and there's a bug report or fix, possibly by a bot or with some static analysis. The maintainer decides to fold it into the original patch, which makes sense for e.g. bisectability. But there seem to be no clear rules about attribution in this case, which looks like there should be, probably in Documentation/maintainer/modifying-patches.rst The original bug fix might include a From: $author, a Reported-by: (e.g. syzbot), Fixes: $next-commit, some tag such as Addresses-Coverity: to credit the static analysis tool, and an SoB. After folding, all that's left might be a line as "include fix from $author" in the SoB area. This is a loss of metadata/attribution just due to folding, and might make contributors unhappy. Had they sent the fix after the original commit was mainline and immutable, all the info above would "survive" in the form of new commit. So I think we could decide what the proper format would be, and document it properly. I personally wouldn't mind just copy/pasting the whole commit message of the fix (with just a short issue description, no need to include stacktraces etc if the fix is folded), we could just standardize where, and how to delimit it from the main commit message. If it's a report (person or bot) of a bug that the main author then fixed, preserve the Reported-by in the same way (making clear it's not a Reported-By for the "main thing" addressed by the commit). In the debate one less verbose alternatve proposed was a SoB with comment describing it's for a fix and not whole patch, as some see SoB as the main mark of contribution, that can be easily found and counted etc. I'm not so sure about it myself, as AFAIK SoB is mainly a DCO thing, and for a maintainer it means something else ("passed through my tree") than for a patch author. And this approach would still lose the other tags. Thoughts? Vlastimil
next reply other threads:[~2020-12-02 23:44 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-02 23:43 Vlastimil Babka [this message] 2020-12-02 23:43 ` crediting bug reports and fixes folded into original patch Vlastimil Babka 2020-12-03 4:02 ` [Ksummit-discuss] " Dan Williams 2020-12-03 4:02 ` Dan Williams 2020-12-03 9:34 ` Leon Romanovsky 2020-12-03 9:34 ` Leon Romanovsky 2020-12-03 9:36 ` Geert Uytterhoeven 2020-12-03 9:36 ` Geert Uytterhoeven 2020-12-03 10:40 ` Leon Romanovsky 2020-12-03 10:40 ` Leon Romanovsky 2020-12-03 18:30 ` Greg KH 2020-12-03 18:30 ` Greg KH 2020-12-03 19:04 ` Leon Romanovsky 2020-12-03 19:04 ` Leon Romanovsky 2020-12-09 0:34 ` Kees Cook 2020-12-09 0:34 ` Kees Cook 2020-12-09 5:01 ` Joe Perches 2020-12-09 5:01 ` Joe Perches 2020-12-09 7:58 ` Dan Carpenter 2020-12-09 7:58 ` Dan Carpenter 2020-12-09 8:45 ` Vlastimil Babka 2020-12-09 8:45 ` Vlastimil Babka 2020-12-09 9:18 ` Geert Uytterhoeven 2020-12-09 9:18 ` Geert Uytterhoeven 2020-12-09 8:54 ` Joe Perches 2020-12-09 8:54 ` Joe Perches 2020-12-09 10:30 ` Dan Carpenter 2020-12-09 10:30 ` Dan Carpenter 2020-12-09 17:45 ` Dan Williams 2020-12-09 17:45 ` Dan Williams 2020-12-03 10:33 ` Dan Carpenter 2020-12-03 10:33 ` Dan Carpenter 2020-12-03 13:41 ` Julia Lawall 2020-12-03 13:41 ` Julia Lawall 2020-12-03 13:58 ` James Bottomley 2020-12-03 13:58 ` James Bottomley 2020-12-03 16:55 ` Joe Perches 2020-12-03 16:55 ` Joe Perches 2020-12-03 19:17 ` Konstantin Ryabitsev 2020-12-03 19:17 ` Konstantin Ryabitsev 2020-12-03 19:24 ` Joe Perches 2020-12-03 19:24 ` Joe Perches 2020-12-03 21:13 ` James Bottomley 2020-12-03 21:13 ` James Bottomley 2020-12-03 18:52 ` Matthew Wilcox 2020-12-03 20:04 ` James Bottomley 2020-12-03 20:04 ` James Bottomley 2020-12-04 4:54 ` Theodore Y. Ts'o 2020-12-04 4:54 ` Theodore Y. Ts'o
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=ea32eb02-5e44-0469-772b-34b5cb882543@suse.cz \ --to=vbabka@suse.cz \ --cc=ksummit-discuss@lists.linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.