lkml.org 
[lkml]   [2022]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v6 05/21] x86/fpu: Make XFD initialization in __fpstate_reset() a function argument
From
On 1/10/22 09:52, Borislav Petkov wrote:
> On Mon, Jan 10, 2022 at 05:15:44AM +0000, Tian, Kevin wrote:
>> Thanks for pointing it out! Actually this is one area which we didn't get
>> a clear answer from 'submitting-patches.rst'
>
> Are you sure? I see
>
> "Any further SoBs (Signed-off-by:'s) following the author's SoB are from
> people handling and transporting the patch, but were not involved in its
> development. SoB chains should reflect the **real** route a patch took
> as it was propagated to the maintainers and ultimately to Linus, with
> the first SoB entry signalling primary authorship of a single author."

Say a patch went A->B->C->A->D and all of {A,B,C} were involved in the
development at different times. The above text says "any further SoBs
are from people not involved in its development", in other words it
doesn't cover the case of multiple people handling different versions of
a patch submission.

The only clear thing from the text would be "do not remove/move the
author's Signed-off-by", but apart from that it's wild wild west and
there are contradictions everywhere.

For example:

1) checkpatch.pl wants "Co-developed-by" to be immediately followed by
"Signed-off-by". Should we imply that all SoB entries preceded by
Co-developed-by do not exactly reflect the route that the patch took
(since there could be multiple back and forth)?

2) if the author sends the patches but has co-developers, should they be
first (because they're the author) or last (because they're the one
actually sending the patch out)?


Any consistent rules that I could come up with are too baroque to be
practical:

1) a sequence consisting of {SoB,Co-developed-by,SoB} does not
necessarily reflect a chain from the first signoff to the second signoff

2) if you are a maintainer committing a patch so that it will go to
Linus, just add your SoB line.

3) if you pick up someone else's branch or posted series, and you are
not in the existing SoB chain, you must add a Co-developed-by and SoB
line for yourself. Do not use the document the changes in brackets:
that is only done by the maintainers when they make changes and do not
repost for review.

The maintainers must already have a bad case of Stockholm syndrome for
not having automated this kind of routine check, but it would be even
worse if we were to inflict this on the developers. In the end, IMHO
the real rules that matter are:

- there should be a SoB line for the author

- the submitter must always have the last SoB line

- SoB lines shall never be removed

- maintainers should prefer merge commits when moving commits from one
tree to the other

- merge commits should have a SoB line too

Everything else, including the existence of Co-developed-by lines, is an
unnecessary complication.

Paolo

\
 
 \ /
  Last update: 2022-01-10 15:18    [W:0.057 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site