mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Konstantin Ryabitsev <>
To: "Ævar Arnfjörð Bjarmason" <>
Cc: Taylor Blau <>, David Caro <>,
Subject: Re: Skipping adding Signed-off-by even if it's not the last on git commit
Date: Wed, 7 Dec 2022 10:00:14 -0500	[thread overview]
Message-ID: <20221207150014.zophrheptrz7456n@nitro.local> (raw)
In-Reply-To: <>

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:
	| 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. :)


      parent reply	other threads:[~2022-12-07 15:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-06 17:06 Skipping adding Signed-off-by even if it's not the last on git commit David Caro
2022-12-07  1:50 ` Taylor Blau
2022-12-07  4:11   ` Junio C Hamano
2022-12-07  8:40     ` David Caro
2022-12-07 22:13       ` Taylor Blau
2022-12-07 23:04         ` Junio C Hamano
2022-12-08  7:27           ` Jeff King
2022-12-09  1:23             ` Junio C Hamano
2022-12-09  1:42               ` Jeff King
2022-12-09  4:03                 ` Junio C Hamano
2022-12-09 20:39                   ` Jeff King
2022-12-07  4:31   ` Ævar Arnfjörð Bjarmason
2022-12-07  4:57     ` Junio C Hamano
2022-12-07 15:00     ` Konstantin Ryabitsev [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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221207150014.zophrheptrz7456n@nitro.local \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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 read-only IMAP folder(s) and NNTP newsgroup(s).