On 10/13/2012 01:17 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 50770155.20700@wwwdotorg.org you wrote:
and in particular, the following parts of that doc is what tells me that committers should always add S-o-b even if the commit didn't change:
Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that:...
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.No, I think you misinterpret this ;-)
This is intended for cases where the original author of the patch shall remain unknown for whatever reasons. Consider some bigger companies doing a lot of their actual development in low-cost countries (say, China). They usually have a ton of developers workignon such stuff, and only one (or very few) people who "interface" ith the community. It is these interface-guys who will add their SoB based on above rule, meaning: yes, I can certify that this is Open Source, and even though the original author shall remain unnamed this can be used freely in this context.
Irrespective of the documentation (which I obviously read the way I describe anyway...), the kernel practice is that everyone who writes or commits a patch adds their S-o-b line, and everyone who simply merges a branch from someone else checks that the provider of the branch added their S-o-b to patches they applied (rather than merged themselves) but does not add their own S-o-b (because it's impossible).
I have often wondered why the merge commits themselves were not signed off by the person performing the merge (which would then logically cover all the commits that got merged). I haven't investigated to find out why though. Doing so would seem to solve your objection about merges.