Linux: Signing Off On Patches

Submitted by Jeremy
on October 3, 2004 - 10:06pm

Back in May, Linux creator Linus Torvalds proposed a method of documenting how patches reach the kernel source tree [story]. The proposal was quickly accepted, and now with each patch that is merged into the mainline kernel you can find one or more lines that begin 'Signed-off-by:', followed by the names of those that have written and reviewed the patches. In a recent query it was asked the proper way to tag a patch that one person has reviewed more than once, specifically wondering if there was a need to sign off on the patch twice. Linus explained:

"I don't think it matters that much, although I personally prefer to see the person who sent it to me ('touched it last') be last in the list. That's partly because of the fact that especially with bigger merges (ie with Andrew), I just do a search-and-replace, and replace any 'signed off by sender' with 'signed off by sender and me'.

"At the same time, I think it's pretty unnecessary (and possibly confusing) to have somebody mentioned twice, so I'd actually prefer to see people just move their (previous) sign-off to be last when they send it on."


From: Dave Hansen [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: Loops in the Signed-off-by process
Date: 	Fri, 01 Oct 2004 12:25:17 -0700

With the recent ppc64 updates, a few patches in my tree didn't merge
very easily.  Being lazy, I asked one of the ppc64 developers to resync
them for me.  But, it happened to be someone other than the original
author that did this.

When they got sent to me again, the original author's (and my)
Signed-off-by: lines were gone, replaced by the nice fellow who merged
them.  This was certainly an artifact of how he generates patches and
obviously not malicious, but I still wonder what the "right" thing to do
is.

Do we show the logical flow?

Signed-off-by: original author
Signed-off-by: patch merger
Signed-off-by: tree maintainer

Or the actual flow of the patches, showing that they came back to the
tree maintainer twice?

Signed-off-by: original author
Signed-off-by: tree maintainer
Signed-off-by: patch merger
Signed-off-by: tree maintainer

Or, does it even really matter?

-- Dave


From: Linus Torvalds [email blocked] Subject: Re: Loops in the Signed-off-by process Date: Fri, 1 Oct 2004 12:39:21 -0700 (PDT) On Fri, 1 Oct 2004, Dave Hansen wrote: > > Or, does it even really matter? I don't think it matters that much, although I personally prefer to see the person who sent it to me ("touched it last") be last in the list. That's partly because of the fact that especially with bigger merges (ie with Andrew), I just do a search-and-replace, and replace any "signed off by sender" with "signed off by sender and me". At the same time, I think it's pretty unnecessary (and possibly confusing) to have somebody mentioned twice, so I'd actually prefer to see people just move their (previous) sign-off to be last when they send it on. Side note: I also like seeing "Acked-by:" or "Cc:" things just above the sign-off lines, because it ends up being useful if there are any technical issues with the patch - if a bug is found, it's very convenient to just take all the sign-off people _and_ the other "involved" people and send off a query to them all. Even if that "Acked-by:" has no other meaning than as a mention of the fact that somebody else was involved in discussions, even if they may not have been involved in actually writing or passing off the ptch. Linus
From: Paul Jackson [email blocked] Subject: Re: Loops in the Signed-off-by process Date: Fri, 1 Oct 2004 13:40:17 -0700 The protocol for adding an Acked-by line mystifies me a little. If I submit a patch after having a good discussion of it with Joe Blow, is it appropriate for me to add an Acked-by line for Joe on my own, or should I get his consent (or know him well enough to know he consents) or should I only so add if Joe asks me to? In other words, does the presence of such a line commit Joe to any position on the patch, beyond perhaps not being too annoyed if he gets queries on it. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [email blocked] 1.650.933.1373
From: Linus Torvalds [email blocked] Subject: Re: Loops in the Signed-off-by process Date: Fri, 1 Oct 2004 13:51:39 -0700 (PDT) On Fri, 1 Oct 2004, Paul Jackson wrote: > > The protocol for adding an Acked-by line mystifies me a little. > > If I submit a patch after having a good discussion of it with > Joe Blow, is it appropriate for me to add an Acked-by line for > Joe on my own, or should I get his consent (or know him well > enough to know he consents) or should I only so add if Joe > asks me to? The "acked-by" thing doesn't mean anything, so you should just use your own judgement. > In other words, does the presence of such a line commit Joe > to any position on the patch, beyond perhaps not being too > annoyed if he gets queries on it. Nope. The annoyance factor is the only factor to take into account. Linus

Related Links:

automation

Anonymous
on
October 4, 2004 - 8:24am

Sounds like there should be a tool of some sort to do this...

RE: automation

Anonymous
on
October 4, 2004 - 9:25am

yes a tool...perfect plan! how would we type one simple line of text without a tool!

RE: automation

Anonymous
on
October 4, 2004 - 5:11pm

Ah, yes. I'm sure you will never forget to update that line in every file.

List order?

Anonymous
on
October 4, 2004 - 5:59pm

If someone moves it's name to the end of the list, there will be no simple way to identify who originally made it.

keep the previous entries

Anonymous
on
October 5, 2004 - 3:13pm

As this system is some sort of document(ation), i don't think this information should be modified from what it has been.

The idea behind it is to be able to trace back trough where the patch went, so this should simply rigidly not be changed just like any other kind of tracking documentation wouldn't.

Datestamp?

on
October 6, 2004 - 8:09am

Why not datestamp the signoffs? That way there's no confusion.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.