ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Vlastimil Babka <vbabka@suse.cz>,
	 "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch
Date: Thu, 03 Dec 2020 05:58:17 -0800	[thread overview]
Message-ID: <694039d6e386d999fd74d038cf2627f5b3b0ca71.camel@HansenPartnership.com> (raw)
In-Reply-To: <ea32eb02-5e44-0469-772b-34b5cb882543@suse.cz>

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

It has been the case since forever that discussion which improves an
uncommitted patch is only captured in email (which now may be preserved
in a link tag).  Patch updates that come in after the patch is
committed get their own commit.  We've tried to move people away from
counting commits as an indicator of upstream eminence, but it's still a
fact of life that this is what matters to a lot of open source
community managers.  The tension we have is between liking a clean
commit in the tree as opposed to a sequence of commits tracking the
evolution of the patch and this community manager desire to track
patches.

So there are two embedded questions here: firstly, should we be as
wedded to clean history as we are, because showing the evolution would
simply solve this?  Secondly, if we are agreed on clean history, how
can we make engagement via email as important as engagement via commit
for the community managers so the Link tag is enough?  I've got to say
I think trying to add tags to recognize patch evolution is a mistake
and we instead investigate one of the two proposals above.

James


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

  parent reply	other threads:[~2020-12-03 13:58 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 [this message]
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=694039d6e386d999fd74d038cf2627f5b3b0ca71.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --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).