ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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

             reply	other threads:[~2020-12-02 23:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 23:43 Vlastimil Babka [this message]
2020-12-03  4:02 ` Dan Williams
2020-12-03  9:34   ` Leon Romanovsky
2020-12-03  9:36     ` Geert Uytterhoeven
2020-12-03 10:40       ` Leon Romanovsky
2020-12-03 18:30         ` Greg KH
2020-12-03 19:04           ` Leon Romanovsky
2020-12-09  0:34           ` Kees Cook
2020-12-09  5:01             ` Joe Perches
2020-12-09  7:58               ` Dan Carpenter
2020-12-09  8:45                 ` Vlastimil Babka
2020-12-09  9:18                   ` Geert Uytterhoeven
2020-12-09  8:54                 ` Joe Perches
2020-12-09 10:30                   ` Dan Carpenter
2020-12-09 17:45                     ` Dan Williams
2020-12-03 10:33 ` Dan Carpenter
2020-12-03 13:41   ` Julia Lawall
2020-12-03 13:58 ` James Bottomley
2020-12-03 16:55   ` Joe Perches
2020-12-03 19:17     ` Konstantin Ryabitsev
2020-12-03 19:24       ` Joe Perches
2020-12-03 21:13       ` James Bottomley
2020-12-03 18:52   ` Matthew Wilcox
2020-12-03 20:04     ` James Bottomley
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 \
    --subject='Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch' \
    /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

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).