Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch

--===============0775012725394655299==
Content-Type: multipart/alternative; boundary="00000000000001a80f05b593dd78"

--00000000000001a80f05b593dd78
Content-Type: text/plain; charset="UTF-8"

It's not so much "clean history" that's the desire. It's "don't leave
landmines for git bisect".

On Thu., Dec. 3, 2020, 08:58 James Bottomley, <
[email protected]> wrote:

> 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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

--00000000000001a80f05b593dd78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">It&#39;s not so much &quot;clean history&quot; that&#39;s=
 the desire. It&#39;s &quot;don&#39;t leave landmines for git bisect&quot;.=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Thu., Dec. 3, 2020, 08:58 James Bottomley, &lt;<a href=3D"mailto:James.B=
[email protected]">[email protected]</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2020-12-03 at 00:=
43 +0100, Vlastimil Babka wrote:<br>
&gt; Hi,<br>
&gt; <br>
&gt; there was a bit of debate on Twitter about this, so I thought I would<=
br>
&gt; bring it here. Imagine a scenario where patch sits as a commit in<br>
&gt; -next and there&#39;s a bug report or fix, possibly by a bot or with s=
ome<br>
&gt; static analysis. The maintainer decides to fold it into the original<b=
r>
&gt; patch, which makes sense for e.g. bisectability. But there seem to be<=
br>
&gt; no clear rules about attribution in this case, which looks like there<=
br>
&gt; should be, probably in<br>
&gt; Documentation/maintainer/modifying-patches.rst<br>
&gt; <br>
&gt; The original bug fix might include a From: $author, a Reported-by:<br>
&gt; (e.g. syzbot), Fixes: $next-commit, some tag such as Addresses-<br>
&gt; Coverity: to credit the static analysis tool, and an SoB. After<br>
&gt; folding, all that&#39;s left might be a line as &quot;include fix from=
<br>
&gt; $author&quot; in the SoB area. This is a loss of metadata/attribution =
just<br>
&gt; due to folding, and might make contributors unhappy. Had they sent<br>
&gt; the fix after the original commit was mainline and immutable, all<br>
&gt; the info above would &quot;survive&quot; in the form of new commit.<br=
>
<br>
It has been the case since forever that discussion which improves an<br>
uncommitted patch is only captured in email (which now may be preserved<br>
in a link tag).=C2=A0 Patch updates that come in after the patch is<br>
committed get their own commit.=C2=A0 We&#39;ve tried to move people away f=
rom<br>
counting commits as an indicator of upstream eminence, but it&#39;s still a=
<br>
fact of life that this is what matters to a lot of open source<br>
community managers.=C2=A0 The tension we have is between liking a clean<br>
commit in the tree as opposed to a sequence of commits tracking the<br>
evolution of the patch and this community manager desire to track<br>
patches.<br>
<br>
So there are two embedded questions here: firstly, should we be as<br>
wedded to clean history as we are, because showing the evolution would<br>
simply solve this?=C2=A0 Secondly, if we are agreed on clean history, how<b=
r>
can we make engagement via email as important as engagement via commit<br>
for the community managers so the Link tag is enough?=C2=A0 I&#39;ve got to=
 say<br>
I think trying to add tags to recognize patch evolution is a mistake<br>
and we instead investigate one of the two proposals above.<br>
<br>
James<br>
<br>
<br>
_______________________________________________<br>
Ksummit-discuss mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_bla=
nk" rel=3D"noreferrer">[email protected]</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discu=
ss" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/mailman/listinfo/ksummit-discuss</a><br>
</blockquote></div>

--00000000000001a80f05b593dd78--

--===============0775012725394655299==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ksummit-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

--===============0775012725394655299==--