ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch
Date: Thu, 3 Dec 2020 23:54:14 -0500	[thread overview]
Message-ID: <20201204045414.GP441757@mit.edu> (raw)
In-Reply-To: <ea32eb02-5e44-0469-772b-34b5cb882543@suse.cz>

On Thu, Dec 03, 2020 at 12:43:52AM +0100, Vlastimil Babka wrote:
> 
> 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

I don't think there should be any kind of fixed, inflexible rules
about this.  

1) Sometimes there will be a *huge* number of comments and
suggestions.  Do we really want to require links to dozens of mail
message id's, and/or dozens or more e-mail addresses?

2) Sometimes a fixup is pretty trivial; even if it is expressed in the
form of a one-line patch, versus someone who does a detailed review of
a patch, but doesn't actually end up appending an explicit
Reviewed-by, perhaps because he or she didn't completely agree with
the final version of the patch.

3) I think this very much should be up to the maintainer's discretion,
as opposed to making rules that may result in some rediculous amount
of bloat in the git log.

4) It's really unhealthy, in my opinion for people to be fixed on
counting attributions.  If we create fixed rules, this can turn into
people try to game the system.  It's the same reason why I'm not
terribly enthusiastic about people trying to game Signed-off-by counts
by sending gazillions of white space or spelling fixes.

If the fix is large enough that for copyright reasons we need to
acknowledge the work, then folding in the SoB as for DCO reason makes
perfect sense.  But if it's a trivial patch (the kind where projects
that require copyright assignment wouldn't require executed legal
agreements), then perhaps attribution is not always a requirement.
Again, there are times when people who spend a lot of work discussing
patch may not get attributiionm even if they didn't actually create
the one-line whitespace fix and sent it in as a patch with a
signed-off-by with a demand that the attribution be preserved.

Common sense really needs to prevale here, and I'm concerned that
people who like to create rules don't realize what a mess this can
create when contributors approach their participation with a sense of
entitlement.

Cheers,

						- Ted
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

      parent reply	other threads:[~2020-12-04  4:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 23:43 Vlastimil Babka
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 [this message]

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=20201204045414.GP441757@mit.edu \
    --to=tytso@mit.edu \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vbabka@suse.cz \
    --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).