Re: Skipping adding Signed-off-by even if it's not the last on git commit

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Wed, Dec 07, 2022 at 05:31:18AM +0100, Ævar Arnfjörð Bjarmason wrote:
> The SOB is a proxy for passing the copyrightable work around, and to
> certify that you have permission to license the work per the DCO etc.
> 
> But it's also interesting in that context that we choose to omit this
> for re-rolls. I.e.:
> 
>  1. I write a patch, that has 10 lines of original work, add a SOB
>  2. You pick it up, add another 10 lines, add your SOB
>  3. I pick it up again, add another 10 lines, add my SOB
> 
> So at the end we have a SOB sequence of: Ævar, Taylor, Ævar, and 30
> copyrightable lines of code.
> 
> But if I submit three versions of my own patch with the same growth
> pattern over those three iterations shouldn't I have 3 of my own SOB
> lines: Ævar, Ævar, Ævar?

I'm not sure the trailer order matters much for the copyright info, because
after all this information is in the output of "git blame" and "git log". That
said, "trailer order" is a touchy subject with kernel developers, because
it means different things to pretty much every kernel maintainer. With b4, I'm
sticking to the "chain of custody" (COC) approach, which treats "S-o-b"
trailers as markers for where the chain of custody boundaries are.

For example, consider the following patch:

    | [PATCH] foo: implement libbar
    |
    | This patch implements libbar.
    |
	| Suggested-by: Reporter 1 <...>
    | Link: https://msgid.link/some-msgid
	| Signed-off-by: Developer 1 <...>     -- initial COC boundary
	| Reviewed-by: Reviewer 1 <...>
	| Tested-by: Tester 1 <...>
	| Signed-off-by: Submaintainer 1 <...> -- intermediate COC boundary
	| Acked-by: Submaintainer 2 <...>
	| Signed-off-by: Maintainer 1 <...>    -- final COC boundary

In terms of COC, this patch makes the following claims:

Developer 1:
 - I am responsible for this code
 - It was suggested by Reporter 1
 - You can read about it at this URL

Submaintainer 1:
 - I am signing off on this code
 - I am the one who added the trailers from Reviewer 1 and Tester 1

Maintainer 1:
 - I am signing off on this code
 - I am the one who added the trailer from Submaintainer 2

In the chain-of-custody scheme multiple identical trailers don't make sense,
as far as I can tell. If the patch doesn't pass review and someone returns it
back to the original developer, their "S-o-b: Developer 1" trailer simply
moves down to be the last entry in v2 of the patch, and the developer should
remove any code review trailers that were issued for the previous version of
the patch.

This is really the only order that makes sense to me. :)

-K