[RFD] Explicitly documenting patch submission

[RFD] Explicitly documenting patch submission

[Linus Torvalds]

Hola!

This is a request for discussion..

Some of you may have heard of this crazy company called SCO (aka "Smoking
Crack Organization") who seem to have a hard time believing that open
source works better than their five engineers do. They've apparently made
a couple of outlandish claims about where our source code comes from,
including claiming to own code that was clearly written by me over a
decade ago.

People have been pretty good (understatement of the year) at debunking
those claims, but the fact is that part of that debunking involved
searching kernel mailing list archives from 1992 etc. Not much fun.

For example, in the case of "ctype.h", what made it so clear that it was
original work was the horrible bugs it contained originally, and since we
obviously don't do bugs any more (right?), we should probably plan on
having other ways to document the origin of the code.

So, to avoid these kinds of issues ten years from now, I'm suggesting that 
we put in more of a process to explicitly document not only where a patch 
comes from (which we do actually already document pretty well in the 
changelogs), but the path it came through. 

Why the full path, and not just originator?

These days, most of the patches in the kernel don't actually get sent
directly to me. That not just wouldn't scale, but the fact is, there's a
lot of subsystems I have no clue about, and thus no way of judging how
good the patch is. So I end up seeing mostly the maintainers of the
subsystem, and when a bug happens, what I want to see is the maintainer
name, not a random developer who I don't even know if he is active any
more. So at least for me, the _chain_ is actually mostly more important
than the actual originator.

There is also another issue, namely the fact than when I (or anybody else,
for that matter) get an emailed patch, the only thing I can see directly
is the sender information, and that's the part I trust. When Andrew sends
me a patch, I trust it because it comes from him - even if the original
author may be somebody I don't know. So the _path_ the patch came in
through actually documents that chain of trust - we all tend to know the
"next hop", but we do _not_ necessarily have direct knowledge of the full
chain.

So what I'm suggesting is that we start "signing off" on patches, to show 
the path it has come through, and to document that chain of trust.  It 
also allows middle parties to edit the patch without somehow "losing" 
their names - quite often the patch that reaches the final kernel is not 
exactly the same as the original one, as it has gone through a few layers 
of people.

The plan is to make this very light-weight, and to fit in with how we 
already pass patches around - just add the sign-off to the end of the 
explanation part of the patch. That sign-off would be just a single line 
at the end (possibly after _other_ peoples sign-offs), saying:

	Signed-off-by: Random J Developer <random@developer.org>

To keep the rules as simple as possible, and yet making it clear what it
means to sign off on the patch, I've been discussing a "Developer's
Certificate of Origin" with a random collection of other kernel
developers (mainly subsystem maintainers).  This would basically be what
a developer (or a maintainer that passes through a patch) signs up for
when he signs off, so that the downstream (upstream?) developers know
that it's all ok:

	Developer's Certificate of Origin 1.0

	By making a contribution to this project, I certify that:

	(a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
	    indicated in the file; or

	(b) The contribution is based upon previous work that, to the best
	    of my knowledge, is covered under an appropriate open source
	    license and I have the right under that license to submit that
	    work with modifications, whether created in whole or in part
	    by me, under the same open source license (unless I am
	    permitted to submit under a different license), as indicated
	    in the file; or

	(c) The contribution was provided directly to me by some other
	    person who certified (a), (b) or (c) and I have not modified
	    it.

This basically allows people to sign off on other peoples patches, as long
as they see that the previous entry in the chain has been signed off on.  
And at the same time it makes the "personal trust" explicit to people who
don't necessarily understand how these things work. 

The above also allows for companies that have "release criteria" to have
the company "release person" sign off on a patch, so that a company can
easily incorporate their own internal release procedures and see that all
the patches have gone through the right channel. At the same time it is
meant to _not_ cause anybody to have to change how they work (ie there is
no "extra paperwork" at any point).

Comments, improvements, ideas? And yes, I know about digital signatures
etc, and that is _not_ what this is about. This is not about proving
authorship - it's about documenting the process. This does not replace or
preclude things like PGP-signed emails, this is _documenting_ how we work,
so that we can show people who don't understand the open source process.

			Linus

Re: [RFD] Explicitly documenting patch submission

[Neil Brown]

On Saturday May 22, torvalds@osdl.org wrote:
> 
> The plan is to make this very light-weight, and to fit in with how we 
> already pass patches around - just add the sign-off to the end of the 
> explanation part of the patch. That sign-off would be just a single line 
> at the end (possibly after _other_ peoples sign-offs), saying:
> 
> 	Signed-off-by: Random J Developer <random@developer.org>
> 

Sounds straight forward enough.

I make sure the appropriate line is at the bottom  of the changelog
comment for every patch I submit.
When I get a patch from someone else that doesn't have their
Signed-off-by line, I either:
  1/ if it is a trivial patch, just add  
               From:  Random J Developer <random@developer.org>
  2/ if it is more substantial (using my own personal definition of
     substantial), I ask them to sign it off.

> 
> 	Developer's Certificate of Origin 1.0

If this is version 1.0, then presumably there might be a version X, 
 X != 1.0  one day. In that case, should the Signed-off-by: tag indicate
 the Certificate of Origin that they are asserting by reference?
e.g.
    Signed-off-by:  Random J Developer <random@developer.org> (certificate=1.0)
or maybe
    Origin-certified-1.0-by: Random J Developer <random@developer.org>

Maybe I'm being too legalistic...

NeilBrown

Re: [RFD] Explicitly documenting patch submission

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Sun, 2004-05-23 at 08:46, Linus Torvalds wrote:
> Hola!
> 
> This is a request for discussion..

Can we make this somewhat less cumbersome even by say, allowing
developers to file a gpg key and sign a certificate saying "all patches
that I sign with that key are hereby under this regime". I know you hate
it but the FSF copyright assignment stuff at least has such "do it once
for forever" mechanism making the pain optionally only once.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFD] Explicitly documenting patch submission

[Greg KH]

On Sun, May 23, 2004 at 10:02:17AM +0200, Arjan van de Ven wrote:
> On Sun, 2004-05-23 at 08:46, Linus Torvalds wrote:
> > Hola!
> > 
> > This is a request for discussion..
> 
> Can we make this somewhat less cumbersome even by say, allowing
> developers to file a gpg key and sign a certificate saying "all patches
> that I sign with that key are hereby under this regime". I know you hate
> it but the FSF copyright assignment stuff at least has such "do it once
> for forever" mechanism making the pain optionally only once.

I don't think that adding a single line to ever patch description is
really "pain".  Especially compared to the FSF proceedure :)

Also, gpg signed patches are a pain to handle on the maintainer's side
of things, speaking from personal experience.  However our patch
handling scripts could probably just be modified to fix this issue, but
no one's stepped up to do it.  And we'd have to start messing with the
whole "web of trust" thing, which would keep us from being able to
accept a patch from someone in a remote location with no way of being
able to add their key to that web, causing _more_ work to be done to get
a patch into the tree than Linus's proposal entails.

thanks,

greg k-h

Re: [RFD] Explicitly documenting patch submission

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

On Sun, May 23, 2004 at 08:25:40AM -0700, Greg KH wrote:
> On Sun, May 23, 2004 at 10:02:17AM +0200, Arjan van de Ven wrote:
> > On Sun, 2004-05-23 at 08:46, Linus Torvalds wrote:
> > > Hola!
> > > 
> > > This is a request for discussion..
> > 
> > Can we make this somewhat less cumbersome even by say, allowing
> > developers to file a gpg key and sign a certificate saying "all patches
> > that I sign with that key are hereby under this regime". I know you hate
> > it but the FSF copyright assignment stuff at least has such "do it once
> > for forever" mechanism making the pain optionally only once.
> 
> I don't think that adding a single line to ever patch description is
> really "pain".  Especially compared to the FSF proceedure :)
> 
> Also, gpg signed patches are a pain to handle on the maintainer's side
> of things, speaking from personal experience.  However our patch
> handling scripts could probably just be modified to fix this issue, but
> no one's stepped up to do it.

I'll buy that

>  And we'd have to start messing with the
> whole "web of trust" thing, which would keep us from being able to
> accept a patch from someone in a remote location with no way of being
> able to add their key to that web, causing _more_ work to be done to get
> a patch into the tree than Linus's proposal entails.

But I don't buy this. No web of trust is needed if all that is happening is
filing a form ONCE saying "all patch submissions signed with THIS key are
automatically certified". That doesn't prevent non-gpg users from using the
proposed mechanism nor involves web of trust metrics.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFD] Explicitly documenting patch submission

[Greg KH]

On Sun, May 23, 2004 at 05:35:10PM +0200, Arjan van de Ven wrote:
> 
> But I don't buy this. No web of trust is needed if all that is happening is
> filing a form ONCE saying "all patch submissions signed with THIS key are
> automatically certified". That doesn't prevent non-gpg users from using the
> proposed mechanism nor involves web of trust metrics.

Ok, but consider my workload.  I measured one month of patches sent to
me recently and it came out to over 300 unique patches from 86 different
developers (and this is during a stable kernel series...)  Now you put
the burden of work on me to verify that this person who just sent me a
signed patch had already sent me a signed form.  That's a lot of work
for me to do, and will slow me down a lot.

But if I only have to check for that one line added to every patch, no
slow down or extra work needs to be done by me (with the exception that
I also add the "Signed off" tag to the patch with my name, but that's
easily automated by me.)  And in reality, not much extra work for you
either (a simple cut and paste for every patch is pretty simple.)

Oh, and with your system, where would these signed forms be stored at?
That would require infrastructure to be built that we currently do not
have.

thanks,

greg k-h

Re: [RFD] Explicitly documenting patch submission

[Matt Mackall]

On Sun, May 23, 2004 at 05:35:10PM +0200, Arjan van de Ven wrote:
> On Sun, May 23, 2004 at 08:25:40AM -0700, Greg KH wrote:
> > On Sun, May 23, 2004 at 10:02:17AM +0200, Arjan van de Ven wrote:
> > > On Sun, 2004-05-23 at 08:46, Linus Torvalds wrote:
> > > > Hola!
> > > > 
> > > > This is a request for discussion..
> > > 
> > > Can we make this somewhat less cumbersome even by say, allowing
> > > developers to file a gpg key and sign a certificate saying "all patches
> > > that I sign with that key are hereby under this regime". I know you hate
> > > it but the FSF copyright assignment stuff at least has such "do it once
> > > for forever" mechanism making the pain optionally only once.
> > 
> > I don't think that adding a single line to ever patch description is
> > really "pain".  Especially compared to the FSF proceedure :)
> > 
> > Also, gpg signed patches are a pain to handle on the maintainer's side
> > of things, speaking from personal experience.  However our patch
> > handling scripts could probably just be modified to fix this issue, but
> > no one's stepped up to do it.
> 
> I'll buy that
> 
> >  And we'd have to start messing with the
> > whole "web of trust" thing, which would keep us from being able to
> > accept a patch from someone in a remote location with no way of being
> > able to add their key to that web, causing _more_ work to be done to get
> > a patch into the tree than Linus's proposal entails.
> 
> But I don't buy this. No web of trust is needed if all that is happening is
> filing a form ONCE saying "all patch submissions signed with THIS key are
> automatically certified". That doesn't prevent non-gpg users from using the
> proposed mechanism nor involves web of trust metrics.

a) without the web of trust, it's not much stronger than the original
method
b) it's a second method so signing off is no longer a uniform process
c) it requires tools and a database
d) it adds significant amounts of cruft to patches
e) said cruft is fragile and won't survive minor edits along the way

That last point is key - we can't propagate a GPG signature upstream
_with revisions_. Trivial revisions of the form 'rediff against latest
kernel' are to be assumed.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [RFD] Explicitly documenting patch submission

[Ian Stirling]

Greg KH wrote:
> On Sun, May 23, 2004 at 10:02:17AM +0200, Arjan van de Ven wrote:
> 
>>On Sun, 2004-05-23 at 08:46, Linus Torvalds wrote:
>>
>>>Hola!
>>>
>>>This is a request for discussion..
>>
>>Can we make this somewhat less cumbersome even by say, allowing
>>developers to file a gpg key and sign a certificate saying "all patches
>>that I sign with that key are hereby under this regime". I know you hate
>>it but the FSF copyright assignment stuff at least has such "do it once
>>for forever" mechanism making the pain optionally only once.
> 
> 
> I don't think that adding a single line to ever patch description is
> really "pain".  Especially compared to the FSF proceedure :)
> 
> Also, gpg signed patches are a pain to handle on the maintainer's side
> of things, speaking from personal experience.  However our patch


Has anyone ever tried to forge the name on a patch, and get it included?

Re: [RFD] Explicitly documenting patch submission

[Greg KH]

On Sun, May 23, 2004 at 04:38:18PM +0100, Ian Stirling wrote:
> 
> Has anyone ever tried to forge the name on a patch, and get it included?

Not that I know of, but that's not the issue here.

greg k-h

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Sun, 23 May 2004, Ian Stirling wrote:
> 
> Has anyone ever tried to forge the name on a patch, and get it included?

Not to my knowledge. It's a bit harder than just technically forging the
email, you also have to forge a certain "context", since most developers
know the "next hop" person anyway, and thus kind of know what to expect.  
You may not see the other person, but that doesn't mean that you can't
recognize his/her way of doing things.

And if you do _not_ know the person that the forged message comes in as,
then you have to check the patch anyway, so ...

That said, forged emails is not what this process would be about. Quite
frankly, I hope we'll some day have "trusted email", but that's kind of an
independent issue, in that I hope it moves in that direction _regardless_ 
of any patch documentation issues..

		Linus

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Sun, 23 May 2004, Arjan van de Ven wrote:
> 
> Can we make this somewhat less cumbersome even by say, allowing
> developers to file a gpg key and sign a certificate saying "all patches
> that I sign with that key are hereby under this regime". I know you hate
> it but the FSF copyright assignment stuff at least has such "do it once
> for forever" mechanism making the pain optionally only once.

One reason that I'd prefer not to is simply the question of "who maintains 
the certificates?"

I certainly don't want to maintain any stateful paperwork with lots of
people. This is why I personally would prefer it all to be totally
state-less.

Also, there is a _fundamental_ problem with signing a patch in a global 
setting: the patches _do_ get modified as they move through the system 
(maybe just bug-fixes, maybe addign a missing piece, maybe removing a 
controversial part). So the signature ends up being valid only on your 
part of the communication, and then after that it needs something else. 

And what I do _not_ want to see is a system where if somebody makes a 
trivial change, it then has to go back to you to be re-signed. That just 
would be horrible.

With those (pretty basic) caveats in mind, I don't see any fundamental
problem in a PGP key approach, if it's a "local" thing between developers.  
In fact, I think PGP-signed patches are something we may want to look at
from a "trust the email" standpoint, but I think it should be a _local_
trust. And part of that "local" trust might be a private agreement between
ddevelopers that "it's ok to add the sign-off line for Arjan when the
patch has come with that PGP signature" when the patch is passed on.

So to me, the sign-off procedure is really about documenting the path, and 
if a PGP key is there in certain parts of the path, then that would be a 
good thing, but I think it's a separate thing from what I'm looking for.

		Linus

Re: [RFD] Explicitly documenting patch submission

[Horst von Brand]

Linus Torvalds <torvalds@osdl.org> said:
> This is a request for discussion..

[...]

> So, to avoid these kinds of issues ten years from now, I'm suggesting that 
> we put in more of a process to explicitly document not only where a patch 
> comes from (which we do actually already document pretty well in the 
> changelogs), but the path it came through. 

How will the path be preserved? Does BK do it now? Can it be transferred
into CVS (for paranoid CVS-won't-screw-us-ever people)? Does this mean
that only the repositories contain the certificates, "final source"
doesn't?

[...]

> To keep the rules as simple as possible, and yet making it clear what it
> means to sign off on the patch, I've been discussing a "Developer's
> Certificate of Origin" with a random collection of other kernel
> developers (mainly subsystem maintainers).  This would basically be what
> a developer (or a maintainer that passes through a patch) signs up for
> when he signs off, so that the downstream (upstream?) developers know
> that it's all ok:
> 
> 	Developer's Certificate of Origin 1.0

[Nice idea snipped]

Just make sure the relevant open source licenses are in Documentation, and
so is the Certificate du jour. And hash out ideas/scripts to retrieve
proof(s) of origin for a particular line (consider its convoluted history,
originated by Joe Random Hacker, modified by Jane Random and rewritten by
Al Hacker, even Aunt Tillie might have touched it ;-).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Sun, 23 May 2004, Horst von Brand wrote:
> 
> > So, to avoid these kinds of issues ten years from now, I'm suggesting that 
> > we put in more of a process to explicitly document not only where a patch 
> > comes from (which we do actually already document pretty well in the 
> > changelogs), but the path it came through. 
> 
> How will the path be preserved? Does BK do it now? Can it be transferred
> into CVS (for paranoid CVS-won't-screw-us-ever people)?

It will just be in the changelog comments, so yes, BK will preserve it.

The path _inside_ BK is different - BK won't update the changelog 
comments, so basically once it hits BK (or any other SCM, for that 
matter), it's up to the SCM to save off the path details. BK does this by 
recording who committed something, and recording merges, so the 
information still exists, but it's no longer in the same format.

> Does this mean that only the repositories contain the certificates,
> "final source" doesn't?

Well, if you use some format that doesn't preserve patch boundaries (like
exporting it to a plain tar-file), then clearly you can't save the patch
submission details either. So yes, if you use just plain CVS to export it,
or do a "bk export -tplain", the information will be gone.  I don't see
how you _could_ save the information at that point - you're literally
asking to "flatten" the submission tree.

> Just make sure the relevant open source licenses are in Documentation, and
> so is the Certificate du jour.

Yes, I was planning on adding it to Documentation, and also putting a big 
pointer to it into Documentation/SubmittingPatches. But this is obviously 
not something I can do unilaterally, so first we'd all need to agree that 
it's a good idea to do this process.

BTW - there are later stages that I would like to do, like having
automated "acknowledgement" emails sent out when a patch hits the main
repository. The same way that people now have robots that send out the
full patches to the patch lists when a patch hits the kernel.org
repository, we can use this thing to have people who have signed up for
acknowledgement be notified each time a patch that they signed off on hits
the repository.

Not everybody will necessarily care, but I know some people have asked for
a positive ack on when their patch finally hits the "official" trees, and
this sign-off procedure would put all the infrastructure in place for
automating that kind of service.

		Linus

Re: [RFD] Explicitly documenting patch submission

[Roman Zippel]

Hi,

On Sun, 23 May 2004, Linus Torvalds wrote:

> The path _inside_ BK is different - BK won't update the changelog 
> comments, so basically once it hits BK (or any other SCM, for that 
> matter), it's up to the SCM to save off the path details. BK does this by 
> recording who committed something, and recording merges, so the 
> information still exists, but it's no longer in the same format.

Then it's also no longer public information, the information about empty 
merges is not available via bkweb or the cvs gateway.

bye, Roman

Re: [RFD] Explicitly documenting patch submission

[Joe Perches]

On Sat, 2004-05-22 at 23:46, Linus Torvalds wrote:
> So what I'm suggesting is that we start "signing off" on patches, to show 
> the path it has come through, and to document that chain of trust.  It 
> also allows middle parties to edit the patch without somehow "losing" 
> their names - quite often the patch that reaches the final kernel is not 
> exactly the same as the original one, as it has gone through a few layers 
> of people.

I suggest that the current BK PULL methods be indirected.

Instead of "signed-off-by", how about an explicit email to the
author(s) and a pre-commit email list with required ACK(s) prior
to commit?  Email acks are perhaps a better chain of trust than
a signature line.

Use of BK has lost some of the "many-eyeballs" positives of the past.
Today's BkCommits-Head list only allows an after-the-fact review.
Frequently, the patch author and sometimes the maintainer are the
only parties to the change.  A pre-commit list could allow comments by
interested parties on patches that today are under reviewed.

Re: [RFD] Explicitly documenting patch submission

[Jeff Garzik]

Joe Perches wrote:
> Use of BK has lost some of the "many-eyeballs" positives of the past.
> Today's BkCommits-Head list only allows an after-the-fact review.
> Frequently, the patch author and sometimes the maintainer are the
> only parties to the change.  A pre-commit list could allow comments by
> interested parties on patches that today are under reviewed.


Although you do have a point, this is not really true.

For my stuff and several other maintainers, the patches generally appear 
To: <maintainer> CC: <mailing list>.  I specificially ask submittors to 
always CC a mailing list.

It is true that the maintainers (subsystem maintainers like me, or 
overall maintainers like Andrew and Linus) sometimes check in patches 
without much review, but even there, I usually send things that would be 
remotely controversial to the linux-ide/netdev/linux-kernel lists.

	Jeff

Re: [RFD] Explicitly documenting patch submission

[Joe Perches]

On Sun, 2004-05-23 at 12:00, Jeff Garzik wrote:
> the patches generally appear
> I usually send

but sometimes don't.  No fault of yours, just how it goes.

> I specificially ask 

but don't require, etc.

I think the more opportunity for review, the better.

Coupling it to documented patch submission process might
prove valuable.

Cheers,  Joe

Re: [RFD] Explicitly documenting patch submission

[Francois Romieu]

Joe Perches <joe@perches.com> :
[...]
> Use of BK has lost some of the "many-eyeballs" positives of the past.
> Today's BkCommits-Head list only allows an after-the-fact review.
> Frequently, the patch author and sometimes the maintainer are the
> only parties to the change.  A pre-commit list could allow comments by
> interested parties on patches that today are under reviewed.

"Die Hard and Linux pre-commit" ?

If people want to review things, there are:
- -mm
- linus -rc
- linux-scsi
- linux-ide
- netdev
- janitor
- bk-commit
- dri (under what ?)
etc.

Imho the (more or less) specialized lists and bk-commit do not work too bad.

--
Ueimor

Re: [RFD] Explicitly documenting patch submission

[Davide Libenzi]

On Sat, 22 May 2004, Linus Torvalds wrote:

> The plan is to make this very light-weight, and to fit in with how we 
> already pass patches around - just add the sign-off to the end of the 
> explanation part of the patch. That sign-off would be just a single line 
> at the end (possibly after _other_ peoples sign-offs), saying:
> 
> 	Signed-off-by: Random J Developer <random@developer.org>
> 
> To keep the rules as simple as possible, and yet making it clear what it
> means to sign off on the patch, I've been discussing a "Developer's
> Certificate of Origin" with a random collection of other kernel
> developers (mainly subsystem maintainers).  This would basically be what
> a developer (or a maintainer that passes through a patch) signs up for
> when he signs off, so that the downstream (upstream?) developers know
> that it's all ok:
> 
> 	Developer's Certificate of Origin 1.0
> 
> 	By making a contribution to this project, I certify that:
> 
> 	(a) The contribution was created in whole or in part by me and I
>             have the right to submit it under the open source license
> 	    indicated in the file; or
> 
> 	(b) The contribution is based upon previous work that, to the best
> 	    of my knowledge, is covered under an appropriate open source
> 	    license and I have the right under that license to submit that
> 	    work with modifications, whether created in whole or in part
> 	    by me, under the same open source license (unless I am
> 	    permitted to submit under a different license), as indicated
> 	    in the file; or
> 
> 	(c) The contribution was provided directly to me by some other
> 	    person who certified (a), (b) or (c) and I have not modified
> 	    it.

Andrew already puts the "From:" thing in the patch comment, so this should 
be simply a matter of replacing "From:" with "Signed-off-by:", preserving 
it in logs, and documenting the thing in the patch submission doc. No?



- Davide

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Sun, 23 May 2004, Davide Libenzi wrote:
> 
> Andrew already puts the "From:" thing in the patch comment, so this should 
> be simply a matter of replacing "From:" with "Signed-off-by:", preserving 
> it in logs, and documenting the thing in the patch submission doc. No?

Yes and no.

Right now it is _Andrew_ that does the From: line from you. In the 
sign-off procedure, it would be _you_ who add the "Signed-off-by:" line 
for yourself.

(And then Andrew would sign off on the fact that you signed off).

Not a big difference, I agree. 

		Linus

Re: [RFD] Explicitly documenting patch submission

[La Monte H.P. Yarroll]

Linus Torvalds wrote:

>On Sun, 23 May 2004, Davide Libenzi wrote:
>  
>
>>Andrew already puts the "From:" thing in the patch comment, so this should 
>>be simply a matter of replacing "From:" with "Signed-off-by:", preserving 
>>it in logs, and documenting the thing in the patch submission doc. No?
>>    
>>
>
>Yes and no.
>
>Right now it is _Andrew_ that does the From: line from you. In the 
>sign-off procedure, it would be _you_ who add the "Signed-off-by:" line 
>for yourself.
>
>(And then Andrew would sign off on the fact that you signed off).
>
>Not a big difference, I agree. 
>  
>
Andrew's From comment is already a little lossy, e.g. most LKSCTP patches
show up as from Sridhar or DaveM even though there's a whole subproject
of developers working behind Sridhar.

I think the proposed process will increase the amount of explicit credit
being recognized--a very good thing IMHO, since this is the core currency
of our gift culture.

-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig

Re: [RFD] Explicitly documenting patch submission

[H. Peter Anvin]

Followup to:  <40B3642C.3070504@timesys.com>
By author:    "La Monte H.P. Yarroll" <piggy@timesys.com>
In newsgroup: linux.dev.kernel
>
> Andrew's From comment is already a little lossy, e.g. most LKSCTP patches
> show up as from Sridhar or DaveM even though there's a whole subproject
> of developers working behind Sridhar.
> 

Yes, and in Linus' changelogs my patches generally show up as akpm,
since Linus' scripts don't pick up Andrew's style of attributions.

	-hpa

Re: [RFD] Explicitly documenting patch submission

[Daniel Phillips]

Hi Linus,

On Sunday 23 May 2004 02:46, Linus Torvalds wrote:
> This basically allows people to sign off on other peoples patches, as long
> as they see that the previous entry in the chain has been signed off on.

Does that mean that when the submission arrives at your end it's supposed to 
have a whole list of Signed-off-bys, one for each person who handled the 
patch?  Or is it only supposed to have one Signed-off-by, as close to the 
original author as possible?  Or one Signed-off-by with multiple upstream 
emails on it?

Regards,

Daniel

Re: [RFD] Explicitly documenting patch submission

[Paul Jackson]

Daniel asked:
> Does that mean that when the submission arrives at your end it's supposed to 
> have a whole list of Signed-off-bys, one for each person who handled the 
> patch?

I can't speak for the Big Penguin, but I'd guess it should have "a whole list."

In general, sign-off's aren't removed, just added.  One exception might
be some corporate release manager, whose duties include disguising
internal company employee names behind some official corporate
"BettyCrocker@GeneralMills.com" pseudonym.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [RFD] Explicitly documenting patch submission

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]



> explanation part of the patch. That sign-off would be just a single line 
> at the end (possibly after _other_ peoples sign-offs), saying:
> 
> 	Signed-off-by: Random J Developer <random@developer.org>

well this obviously needs to include that you signed off on the DCO and
not some other random piece of paper, and it probably should include the
DCO revision number you signed off on.
Without the former the Signed-off-by: line is entirely empty afaics,
without the later we're not future proof.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFD] Explicitly documenting patch submission

[Steven Cole]

On May 25, 2004, at 1:06 AM, Arjan van de Ven wrote:

>
>
>> explanation part of the patch. That sign-off would be just a single 
>> line
>> at the end (possibly after _other_ peoples sign-offs), saying:
>>
>> 	Signed-off-by: Random J Developer <random@developer.org>
>
> well this obviously needs to include that you signed off on the DCO and
> not some other random piece of paper, and it probably should include 
> the
> DCO revision number you signed off on.
> Without the former the Signed-off-by: line is entirely empty afaics,
> without the later we're not future proof.
>
>

How about something like:

	DCO 1.0 Signed-off-by: Random J Developer <random@developer.org>

This new process being "an ounce of prevention is worth a pound
of cure" should retain the property of being lightweight and not
unduly burdensome.  This change seems to fall into that category.

	Steven 
   

Re: [RFD] Explicitly documenting patch submission

[Bradley Hook]

Steven Cole wrote:
> 
> On May 25, 2004, at 1:06 AM, Arjan van de Ven wrote:
> 
>>
>>
>>> explanation part of the patch. That sign-off would be just a single line
>>> at the end (possibly after _other_ peoples sign-offs), saying:
>>>
>>>     Signed-off-by: Random J Developer <random@developer.org>
>>
>>
>> well this obviously needs to include that you signed off on the DCO and
>> not some other random piece of paper, and it probably should include the
>> DCO revision number you signed off on.
>> Without the former the Signed-off-by: line is entirely empty afaics,
>> without the later we're not future proof.
>>
>>
> 
> How about something like:
> 
>     DCO 1.0 Signed-off-by: Random J Developer <random@developer.org>
> 
> This new process being "an ounce of prevention is worth a pound
> of cure" should retain the property of being lightweight and not
> unduly burdensome.  This change seems to fall into that category.
> 
>     Steven  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Why not design the DCO so that it assumes an author accepts the most 
recent published version unless specified. You could then shorten the 
line to:

DCO-Sign-Off: Random J Developer <random@developer.org>

And if they wanted to specify a version, use something like:

DCO-Sign-Off: Random J Developer <random@developer.org> [DCO 1.0]

You could also define the signoff line to use different delimiters for 
various types of information, to allow for all of these "custom" ideas 
that contributing companies may feel they "need".

For example, say any text not enclosed by any delimiters is considered a 
name, anything in <> is an email, in [] is a DCO version, and {} allows 
for optional information. This would allow for stuff like Yarroll 
submitted while I was typing this email, for example:

DCO-Sign-Off: La Monte H.P. Yarroll <piggy@timesys.com> [DCO 1.0] {TS00062}

Nothing other than name and email would be required, but they would be 
available for those that wish to use them. This would make it easy for 
scripts to sort out the info on this line.

~Brad

Re: [RFD] Explicitly documenting patch submission

[La Monte H.P. Yarroll]

Bradley Hook wrote:

> Steven Cole wrote:
>
>>
>> On May 25, 2004, at 1:06 AM, Arjan van de Ven wrote:
>>
>>>> explanation part of the patch. That sign-off would be just a single 
>>>> line
>>>> at the end (possibly after _other_ peoples sign-offs), saying:
>>>>
>>>>     Signed-off-by: Random J Developer <random@developer.org>
>>>
>>>
>>>
>>> well this obviously needs to include that you signed off on the DCO and
>>> not some other random piece of paper, and it probably should include 
>>> the
>>> DCO revision number you signed off on.
>>> Without the former the Signed-off-by: line is entirely empty afaics,
>>> without the later we're not future proof.
>>>
>>>
>>
>> How about something like:
>>
>>     DCO 1.0 Signed-off-by: Random J Developer <random@developer.org>
>>
>> This new process being "an ounce of prevention is worth a pound
>> of cure" should retain the property of being lightweight and not
>> unduly burdensome.  This change seems to fall into that category.
>>
>>     Steven  -
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
> Why not design the DCO so that it assumes an author accepts the most 
> recent published version unless specified. You could then shorten the 
> line to:
>
> DCO-Sign-Off: Random J Developer <random@developer.org>

If I'm looking at a 15 year old document where do I go to find out what
"most recent published version" meant at that time?  This assumes we're
talking about a document that has a clear timestamp.  If we care about
the version number at all, it should be in every signoff line.

-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig

Re: [RFD] Explicitly documenting patch submission

[Bradley Hook]

La Monte H.P. Yarroll wrote:
> 
>>
>> Why not design the DCO so that it assumes an author accepts the most 
>> recent published version unless specified. You could then shorten the 
>> line to:
>>
>> DCO-Sign-Off: Random J Developer <random@developer.org>
> 
> 
> If I'm looking at a 15 year old document where do I go to find out what
> "most recent published version" meant at that time?  This assumes we're
> talking about a document that has a clear timestamp.  If we care about
> the version number at all, it should be in every signoff line.
> 

It's similar to when an author licenses something under GPL with:

"either version 2 of the License, or (at your option) any later version."

By doing this, you are trusting that whoever is in charge of releasing a 
new revision of the DCO is not going to put something in there that 
would alter the base meaning or intent of the DCO; Only corrections or 
additions to allow for special cases. Notice that the DCO reads as 3 
options ORed together, which means only 1 has to be true. If that design 
were maintained, then any additions/corrections should not have an 
affect on an old sign-off.

If anyone is concerned about this, then they should include a version 
number in the sign off. But put the version after the line identifier 
(Signed-off-by:), and only if you - the person signing off - are going 
to care about it. But if you're that paranoid, you should probably also 
be explicitly stating which option you are signing off on, and "what 
DCO" you are using...

DCO 1.0(a) as submitted by Linus Torvalds on the LKML on 5/23/04: Random 
J Developer <random@developer.org>

Come on now, get serious.

~Brad

Re: [RFD] Explicitly documenting patch submission

[Daniel Phillips]

On Tuesday 25 May 2004 14:51, La Monte H.P. Yarroll wrote:
> If I'm looking at a 15 year old document where do I go to find out what
> "most recent published version" meant at that time?

You look in the kernel version to which the patch was contributed, that should 
be close enough.

Regards,

Daniel

Re: [RFD] Explicitly documenting patch submission

[Ben Collins]

I've got a question about this. A lot of times I get patches that are
just one/two-liners and the explanation is somewhat self-explantory,
etc. Say the patch comes to me from some patch collection maintainer,
who got it from the original author.

So the original person never put a Signed-off-by, and neither did the
person who sent me the patch, should I still add the eplicit
Signed-off-by's to the patch, and add myself, before sending it to you?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Tue, 25 May 2004, Ben Collins wrote:
>
> I've got a question about this. A lot of times I get patches that are
> just one/two-liners and the explanation is somewhat self-explantory,
> etc. Say the patch comes to me from some patch collection maintainer,
> who got it from the original author.
> 
> So the original person never put a Signed-off-by, and neither did the
> person who sent me the patch, should I still add the eplicit
> Signed-off-by's to the patch, and add myself, before sending it to you?

You should never sign off for somebody else.

You _can_ sign off as yourself, and just add a note of "From xxxx". That's
what the (b) case is all about (ie "to the best of my knowledge it's
already under a open-source license").

Of course, if it's a _big_ work with lots of original content, and you're 
unsure of exactly what the original author wanted to do with this, you 
obviously should _not_ sign off on it. But you knew that.

			Linus

Re: [RFD] Explicitly documenting patch submission

[Ben Collins]

On Tue, May 25, 2004 at 10:15:15AM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 25 May 2004, Ben Collins wrote:
> >
> > I've got a question about this. A lot of times I get patches that are
> > just one/two-liners and the explanation is somewhat self-explantory,
> > etc. Say the patch comes to me from some patch collection maintainer,
> > who got it from the original author.
> > 
> > So the original person never put a Signed-off-by, and neither did the
> > person who sent me the patch, should I still add the eplicit
> > Signed-off-by's to the patch, and add myself, before sending it to you?
> 
> You should never sign off for somebody else.
> 
> You _can_ sign off as yourself, and just add a note of "From xxxx". That's
> what the (b) case is all about (ie "to the best of my knowledge it's
> already under a open-source license").
> 
> Of course, if it's a _big_ work with lots of original content, and you're 
> unsure of exactly what the original author wanted to do with this, you 
> obviously should _not_ sign off on it. But you knew that.

I know you want this simple, but should we keep the paper-trail momentum
going by adding a "Submitted-by"? Like if I get a one-liner fix, which
is obviously not adding new code, rather than go through the whole
process of asking for them to agree to the signoff deal, could I do:

Submitted-by: Jimmy Janitor <jimmy@janitor.blah>
Signed-off-by: Ben Collins <bcollins@debian.org>

? I like the idea of knowing where a patch came from and via who. This
would make it easier to analyze that info, but keep it simple for
trivial patches that so many of us get (in the (b) case).

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: [RFD] Explicitly documenting patch submission

[Dave Jones]

On Tue, May 25, 2004 at 01:18:05PM -0400, Ben Collins wrote:

 > I know you want this simple, but should we keep the paper-trail momentum
 > going by adding a "Submitted-by"? Like if I get a one-liner fix, which
 > is obviously not adding new code, rather than go through the whole
 > process of asking for them to agree to the signoff deal, could I do:
 > 
 > Submitted-by: Jimmy Janitor <jimmy@janitor.blah>
 > Signed-off-by: Ben Collins <bcollins@debian.org>
 > 
 > ? I like the idea of knowing where a patch came from and via who. This
 > would make it easier to analyze that info, but keep it simple for
 > trivial patches that so many of us get (in the (b) case).

For trivial one liners, it's usually quicker for me to
just hack the file myself than to save the diff, run it through
patch, delete the diff when I'm done etc.  When I do this
I usually put in the changelog "pointed out by Joe Hacker".
My reasoning behind this is that all typos are then mine 8-)
whilst still crediting the person who did the original.

Likewise if I fix something in a slightly different way
to how the patch that was submitted did it, as the person
reporting still did some work which they should be credited for,
even if ultimately their solution wasn't used, but was used
as a basis for the real fix.

In these cases, I think it'd be reasonable to have..

Signed-off-by: Dave Jones <davej@redhat.com>
Spotted-by: Joe Hacker <joe@scoblows.com>

As asking submitters to sign off on modified versions
of their patch would be silly overhead IMO.

Linus?

		Dave

Re: [RFD] Explicitly documenting patch submission

[Ben Collins]

> Signed-off-by: Dave Jones <davej@redhat.com>
> Spotted-by: Joe Hacker <joe@scoblows.com>
> 
> As asking submitters to sign off on modified versions
> of their patch would be silly overhead IMO.

That's fine with me too. I could definitely see there being 2 or 3
headers that mid-level developers could use to identify the origin of a
patch and they could be documented.

Linus could just concern himself with atleast us subsystem-maintainers
putting the Signed-off-by on there and not worry himself about the other
headers.

Could have something like:

Spotted-by: Foo
Submitted-by: Bar
Signed-off-by: Ben Collins

And if there's a problem, Linus can come knocking on my door for fucking
up, and I'd be the bottom line responsible for the submission. Linus
need only put his confidence on a small subset of patch submitters (like
he mainly does now) doing the Signed-off-by.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Tue, 25 May 2004, Ben Collins wrote:
> 
> Linus could just concern himself with atleast us subsystem-maintainers
> putting the Signed-off-by on there and not worry himself about the other
> headers.

Note that this is how it's supposed to always work, except you should 
replace "Linus" with "any maintainer".

At any point in the chain, you should always have to worry only about the
"immediate predecessor". That's why the certificate is "recursive", ie if
the immediate predecessor signed off, then you can always sign off
yourself, without worrying about any history, and you've done the "right
thing".

		Linus

Re: [RFD] Explicitly documenting patch submission

[raven]

On Sat, 22 May 2004, Linus Torvalds wrote:

> This is a request for discussion..
>

There's certainly been a lot of that so far.

Please forgive my interrupting but am I missing something ...

Would it be possible to define a convention for log entries like with 
keyword expansions in CVS $Log$ and have it include the expected 
brief patch description? Simple, easy and automated but probably doesn't 
work with everyones' version control systems.

Just a thought.

Ian

Re: [RFD] Explicitly documenting patch submission

[La Monte H.P. Yarroll]

Linus Torvalds wrote:

>The plan is to make this very light-weight, and to fit in with how we 
>already pass patches around - just add the sign-off to the end of the 
>explanation part of the patch. That sign-off would be just a single line 
>at the end (possibly after _other_ peoples sign-offs), saying:
>
>	Signed-off-by: Random J Developer <random@developer.org>
>  
>
To avoid the requirement of all submissions going through a single person,
we have a system of formal authorizations. Specific people are authorized
to release certain classes of work. Would the community object to a slight
modifications to the Signed-off-by lines from TimeSys? E.g.

Signed-off-by: La Monte H.P. Yarroll <piggy@timesys.com> under TS00062

This completes the traceability path all the way back to the VP who signed
off on TS00062.

>To keep the rules as simple as possible, and yet making it clear what it
>means to sign off on the patch, I've been discussing a "Developer's
>Certificate of Origin" with a random collection of other kernel
>developers (mainly subsystem maintainers).  This would basically be what
>a developer (or a maintainer that passes through a patch) signs up for
>when he signs off, so that the downstream (upstream?) developers know
>that it's all ok:
>
>	Developer's Certificate of Origin 1.0
>
>	By making a contribution to this project, I certify that:
>
>	(a) The contribution was created in whole or in part by me and I
>            have the right to submit it under the open source license
>	    indicated in the file; or
>
>	(b) The contribution is based upon previous work that, to the best
>	    of my knowledge, is covered under an appropriate open source
>	    license and I have the right under that license to submit that
>	    work with modifications, whether created in whole or in part
>	    by me, under the same open source license (unless I am
>	    permitted to submit under a different license), as indicated
>	    in the file; or
>
>	(c) The contribution was provided directly to me by some other
>	    person who certified (a), (b) or (c) and I have not modified
>	    it.
>  
>

I THINK I have a case not covered here. I sometimes need to post unpublished
work done by other people at my company. Since the work is not yet 
published,
the GPL doesn't really grant me any special rights. The authorization I use
to publish is in fact NOT an open source license. I think clause (b) could
probably be weakened to cover my case.

>...
>The above also allows for companies that have "release criteria" to have
>the company "release person" sign off on a patch, so that a company can
>easily incorporate their own internal release procedures and see that all
>the patches have gone through the right channel. At the same time it is
>meant to _not_ cause anybody to have to change how they work (ie there is
>no "extra paperwork" at any point).
>  
>
I'd like to include a link between the external path and our internal 
procedures.

-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Tue, 25 May 2004, La Monte H.P. Yarroll wrote:
>
> Linus Torvalds wrote:
> 
> >The plan is to make this very light-weight, and to fit in with how we 
> >already pass patches around - just add the sign-off to the end of the 
> >explanation part of the patch. That sign-off would be just a single line 
> >at the end (possibly after _other_ peoples sign-offs), saying:
> >
> >	Signed-off-by: Random J Developer <random@developer.org>
>
> To avoid the requirement of all submissions going through a single person,
> we have a system of formal authorizations. Specific people are authorized
> to release certain classes of work. Would the community object to a slight
> modifications to the Signed-off-by lines from TimeSys? E.g.
> 
> Signed-off-by: La Monte H.P. Yarroll <piggy@timesys.com> under TS00062
> 
> This completes the traceability path all the way back to the VP who signed
> off on TS00062.

I think this is great. In general, I think people who want to add their 
own extra tags after their email address should be able to do so. We might 
even have a few standard tags for things like asking for acknowledgement 
etc.

> I THINK I have a case not covered here. I sometimes need to post
> unpublished work done by other people at my company. Since the work is
> not yet published, the GPL doesn't really grant me any special rights.
> The authorization I use to publish is in fact NOT an open source
> license. I think clause (b) could probably be weakened to cover my case.

I think the "(unless I am permitted to submit under a different license)" 
part already covers that,  but yes, if we want to get really technically 
anal about it we migth spell it out.

> I'd like to include a link between the external path and our internal 
> procedures.

Would the extra tag at the end be sufficient for that, or are you talking 
about something more?

		Linus

Re: [RFD] Explicitly documenting patch submission

[La Monte H.P. Yarroll]

Linus Torvalds wrote:

>On Tue, 25 May 2004, La Monte H.P. Yarroll wrote:
>  
>
>>Linus Torvalds wrote:
>>
>>    
>>
>>>The plan is to make this very light-weight, and to fit in with how we 
>>>already pass patches around - just add the sign-off to the end of the 
>>>explanation part of the patch. That sign-off would be just a single line 
>>>at the end (possibly after _other_ peoples sign-offs), saying:
>>>
>>>	Signed-off-by: Random J Developer <random@developer.org>
>>>      
>>>
>>To avoid the requirement of all submissions going through a single person,
>>we have a system of formal authorizations. Specific people are authorized
>>to release certain classes of work. Would the community object to a slight
>>modifications to the Signed-off-by lines from TimeSys? E.g.
>>
>>Signed-off-by: La Monte H.P. Yarroll <piggy@timesys.com> under TS00062
>>
>>This completes the traceability path all the way back to the VP who signed
>>off on TS00062.
>>    
>>
>
>I think this is great. In general, I think people who want to add their 
>own extra tags after their email address should be able to do so. We might 
>even have a few standard tags for things like asking for acknowledgement 
>etc.
>  
>
Thanks.

>>I THINK I have a case not covered here. I sometimes need to post
>>unpublished work done by other people at my company. Since the work is
>>not yet published, the GPL doesn't really grant me any special rights.
>>The authorization I use to publish is in fact NOT an open source
>>license. I think clause (b) could probably be weakened to cover my case.
>>    
>>
>
>I think the "(unless I am permitted to submit under a different license)" 
>part already covers that,  but yes, if we want to get really technically 
>anal about it we migth spell it out.
>  
>
It's an occupational hazzard for me--I talk to lawyers too much :-).  Let me
see if I can get a blessed recommendation for rephrasing clause (b).

I don't think the authorizations I work with qualify as licenses.

>>I'd like to include a link between the external path and our internal 
>>procedures.
>>    
>>
>
>Would the extra tag at the end be sufficient for that, or are you talking 
>about something more?
>  
>
The extra tag suffices.

-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig

Re: [RFD] Explicitly documenting patch submission

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Tue, 25 May 2004 11:44:21 EDT, "La Monte H.P. Yarroll" said:

> I THINK I have a case not covered here. I sometimes need to post unpublished
> work done by other people at my company. Since the work is not yet 
> published,
> the GPL doesn't really grant me any special rights. The authorization I use
> to publish is in fact NOT an open source license. I think clause (b) could
> probably be weakened to cover my case.

Hmm.. I'm missing something here.

It's unclear (at least to me) whether your issue is:

a) You're submitting patches that consist of GPL'able code that you don't have
the company-internal paperwork in place to authorize the release; or

b) The patches you're releasing aren't GPL'able because they're in some way
encumbered by a licensing issue.

In either case, we need to clarify and fix the problem, totally separate from
the DCO issue (all *that* does is that if somebody points out a problem with a
patch of yours down the road, we know to ask *you* about it....)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Tue, 25 May 2004 Valdis.Kletnieks@vt.edu wrote:
> 
> It's unclear (at least to me) whether your issue is:
> 
> a) You're submitting patches that consist of GPL'able code that you don't have
> the company-internal paperwork in place to authorize the release; or

No, if I understood correctly he _does_ have all the rights internally,
and it's just that he didn't write it, so (a) doesn't apply, and because
the people who _did_ write it are all internal and don't themselves have
the right to release it as GPL, (b) doesn't apply either (the "preexisting
work" wasn't GPL'd, but it will be once he follows the rules).

Technically, I do believe (b) applies just because if he has the right to 
make it GPL'd, then he can (and should) just exercise that right _before_ 
he agrees to sign it off as per (b).

So I think the current DCO thing should be ok.

I really didn't want this to degrade into some lawyerese, and I _really_
don't want the "certificate of origin" to become some horrible thing that 
only a lawyer could love.

		Linus

Re: [RFD] Explicitly documenting patch submission

[J. Bruce Fields]

On Sat, May 22, 2004 at 11:46:29PM -0700, Linus Torvalds wrote:
> This is not about proving authorship - it's about documenting the
> process. This does not replace or preclude things like PGP-signed
> emails, this is _documenting_ how we work, so that we can show people
> who don't understand the open source process.

What aspects of the process do you want to document?

The patch-submission process can be more complicated than a simple path
up a heirarchy of maintainers--patches get bounced around a lot
sometimes.

If you're trying to document who contributes "intellectual property" to
the kernel, then documenting the process of creating the patch would
seem more important than documenting the actual submission--any
significant change is often the result of complicated discussions
between multiple parties who wouldn't necessarily appear in the chain of
submittors.

I gues I'm still a little vague as to exactly what sort of questions we
expect to be able to answer using this new documentation.

A couple examples (which I think aren't too farfetched):
	* Developer A submits a patch which is dropped by maintainer B.
	  I later notice this and resubmit A's patch to B.  I don't
	  change the patch at all, and the resubmission is my only
	  contribution to the process.  Do I need to tag on my own
	  "Signed-off-by" line?
	* I write a patch.  Developers X and Y suggest significant
	  changes.  I make the changes before I submit them to maintainer
	  Z.  Suppose the changes are significant enough that I no longer
	  feel comfortable representing myself as the sole author of the
	  patch.  Should I also be asking developer X  and Y to add their
	  own "Signed-off-by" lines?

--Bruce Fields

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Tue, 25 May 2004, J. Bruce Fields wrote:
> 
> The patch-submission process can be more complicated than a simple path
> up a heirarchy of maintainers--patches get bounced around a lot
> sometimes.

Yes. And documenting the complex relationships obviously can't be sanely 
done. The best we can do is a "it went through these people".

Perfect is the enemy of good. If we tried to be perfect, we'd never get 
anything done.

> If you're trying to document who contributes "intellectual property" to
> the kernel

No, that's not what it is either.  At least to me, equally important as 
the actual author is how it got reviewed, and what path it took. Because 
when problems happen (say a simple bug), I want the whole path to know.

Think of it this way (purely technical to avoid any emotional arguments):  
we've hunted down a change that results in strange behaviour, and what we
want to do is get the problem explained and resolved. Maybe the thing to 
do is to just revert the whole change, but usually we just want to fix it, 
and regardless of whether we want to undo it or fix it, what we want to do 
is get the people who were involved with not just writing the code, but 
approving it too to look at the issue.

And the people who approved it literally _are_ as important as the people 
who wrote it (forget any copyright issues), since (a) they need to know to 
avoid the problem in the first place and (b) they usually know why the 
code was added and what problems _they_ saw (or didn't see) when they 
approved it.

See? That's why to me, the set of people who have been involved in the
whole patch "lifetime" is actually _more_ important than the original
author. The original author is obviously special in some respects, but
from a problem solving perspective he's not necessarily even the person to
go to.

> I gues I'm still a little vague as to exactly what sort of questions we
> expect to be able to answer using this new documentation.

See above. I explicitly picked a _technical_ reason for tracking who has
been involved with a patch, but let's say that somebody raises concerns
over any _other_ issues about the code - the fact is that the same logic 
applies. The original author is a bit special, but the path it took is 
still equally important.

> A couple examples (which I think aren't too farfetched):
> 	* Developer A submits a patch which is dropped by maintainer B.
> 	  I later notice this and resubmit A's patch to B.  I don't
> 	  change the patch at all, and the resubmission is my only
> 	  contribution to the process.  Do I need to tag on my own
> 	  "Signed-off-by" line?

Yup. And part of it is simply credit: trust me when I say to you that
"maintenance" of patches is a job that it at _least_ as important as
writing them in most cases.

That's not always true, of course - there are pieces of code that are just
stunning works of art, and very important, and as programmers we like to 
think of those really fundamental contributions. But in real life, it's 
definitely the old case of "1% inspiration, 99% persiration", and we 
should just accept that.

For example, look at the kernel developers out there, and ask yourself who 
stands out. There's a couple of great coders, but I think the people who 
really stand out are people like Andrew, who mostly really "organize" and 
act as managers. Right?

So when you save a patch from oblivion by passing it on to the right 
person, and get it submitted when it was originally dropped by some 
reason, you're actually doing a fundamentally important job. Maybe it's 
just one small piece of the puzzle, but hey, you'd only get one small line 
in the changeset, so the credit (or blame ;) really is appropriate.

> 	* I write a patch.  Developers X and Y suggest significant
> 	  changes.  I make the changes before I submit them to maintainer
> 	  Z.  Suppose the changes are significant enough that I no longer
> 	  feel comfortable representing myself as the sole author of the
> 	  patch.  Should I also be asking developer X  and Y to add their
> 	  own "Signed-off-by" lines?

That, my friend, is a matter of your own taste and conscience. My answer
is that if you wrote it all, you clearly don't _need_ to. At the same
time, I think that it's certainly in good taste to at least _ask_ them. 
Wouldn't you agree?

		Linus

Re: [RFD] Explicitly documenting patch submission

[Andy Isaacson]

On Tue, May 25, 2004 at 10:05:26AM -0700, Linus Torvalds wrote:
> On Tue, 25 May 2004, J. Bruce Fields wrote:
> > The patch-submission process can be more complicated than a simple path
> > up a heirarchy of maintainers--patches get bounced around a lot
> > sometimes.
> 
> Yes. And documenting the complex relationships obviously can't be sanely 
> done. The best we can do is a "it went through these people".
> 
> Perfect is the enemy of good. If we tried to be perfect, we'd never get 
> anything done.

Agreed, but...

> > 	* I write a patch.  Developers X and Y suggest significant
> > 	  changes.  I make the changes before I submit them to maintainer
> > 	  Z.  Suppose the changes are significant enough that I no longer
> > 	  feel comfortable representing myself as the sole author of the
> > 	  patch.  Should I also be asking developer X  and Y to add their
> > 	  own "Signed-off-by" lines?
> 
> That, my friend, is a matter of your own taste and conscience. My answer
> is that if you wrote it all, you clearly don't _need_ to. At the same
> time, I think that it's certainly in good taste to at least _ask_ them. 
> Wouldn't you agree?

This is one example of a general class of problem; another example is
"Andrew integrated 15 patches into -mm5".  When you have an aggregate
work representing a conglomeration of works from several different
developers, it becomes unwieldy to apply "tags" as you're suggesting.

What if I send a patch to l-k, and Bruce forwards it on to Andrew;
meanwhile, Joe sends another patch to l-k and Peter forwards it on to
Andrew.  Andrew integrates both patches, as well as several unrelated
bits he creates himself, into -mm77, which he sends to Linus and gets
integrated.

My signature can only apply to the patch I submitted, but that
distinction has been demolished long before the patch got anywhere near
a database that might be able to record it.  If we get lucky, the patch
in the l-k archives might be recognizable in -mm77.patch and the
resultant cset.

This problem is somewhat mitigated if all "aggregators" use BK, since
BKs csets preserve the boundaries of attestation that are interesting
here.  But it's not reasonable or sane to try to filter this problem
through BK.

-andy

Re: [RFD] Explicitly documenting patch submission

[Matt Mackall]

On Tue, May 25, 2004 at 01:08:34PM -0500, Andy Isaacson wrote:
> On Tue, May 25, 2004 at 10:05:26AM -0700, Linus Torvalds wrote:
> > On Tue, 25 May 2004, J. Bruce Fields wrote:
> > > The patch-submission process can be more complicated than a simple path
> > > up a heirarchy of maintainers--patches get bounced around a lot
> > > sometimes.
> > 
> > Yes. And documenting the complex relationships obviously can't be sanely 
> > done. The best we can do is a "it went through these people".
> > 
> > Perfect is the enemy of good. If we tried to be perfect, we'd never get 
> > anything done.
> 
> Agreed, but...
> 
> > > 	* I write a patch.  Developers X and Y suggest significant
> > > 	  changes.  I make the changes before I submit them to maintainer
> > > 	  Z.  Suppose the changes are significant enough that I no longer
> > > 	  feel comfortable representing myself as the sole author of the
> > > 	  patch.  Should I also be asking developer X  and Y to add their
> > > 	  own "Signed-off-by" lines?
> > 
> > That, my friend, is a matter of your own taste and conscience. My answer
> > is that if you wrote it all, you clearly don't _need_ to. At the same
> > time, I think that it's certainly in good taste to at least _ask_ them. 
> > Wouldn't you agree?
> 
> This is one example of a general class of problem; another example is
> "Andrew integrated 15 patches into -mm5".  When you have an aggregate
> work representing a conglomeration of works from several different
> developers, it becomes unwieldy to apply "tags" as you're suggesting.
> 
> What if I send a patch to l-k, and Bruce forwards it on to Andrew;
> meanwhile, Joe sends another patch to l-k and Peter forwards it on to
> Andrew.  Andrew integrates both patches, as well as several unrelated
> bits he creates himself, into -mm77, which he sends to Linus and gets
> integrated.

But -mm is actually maintained as a serial set of patches, each
submitted independently. Occassionally patches are rolled together
here, but that's the exception.

The case I'm still worried about is something like a filesystem that
gets worked on out-of-tree for an extended period of time and gets
submitted in a lump. If it's developed inside the confines of a
corporation, sure, it can be signed off by one person in authority,
but if it's developed in the open with numerous outside submissions,
it's less clear what the right thing is. Aggregating 500
signed-off-bys might get messy.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [RFD] Explicitly documenting patch submission

[Pavel Machek]

Hi!

> > > > The patch-submission process can be more complicated than a simple path
> > > > up a heirarchy of maintainers--patches get bounced around a lot
> > > > sometimes.
> > > 
> > > Yes. And documenting the complex relationships obviously can't be sanely 
> > > done. The best we can do is a "it went through these people".
> > > 
> > > Perfect is the enemy of good. If we tried to be perfect, we'd never get 
> > > anything done.
> > 
> > Agreed, but...
> > 
> > > > 	* I write a patch.  Developers X and Y suggest significant
> > > > 	  changes.  I make the changes before I submit them to maintainer
> > > > 	  Z.  Suppose the changes are significant enough that I no longer
> > > > 	  feel comfortable representing myself as the sole author of the
> > > > 	  patch.  Should I also be asking developer X  and Y to add their
> > > > 	  own "Signed-off-by" lines?
> > > 
> > > That, my friend, is a matter of your own taste and conscience. My answer
> > > is that if you wrote it all, you clearly don't _need_ to. At the same
> > > time, I think that it's certainly in good taste to at least _ask_ them. 
> > > Wouldn't you agree?
> > 
> > This is one example of a general class of problem; another example is
> > "Andrew integrated 15 patches into -mm5".  When you have an aggregate
> > work representing a conglomeration of works from several different
> > developers, it becomes unwieldy to apply "tags" as you're suggesting.
> > 
> > What if I send a patch to l-k, and Bruce forwards it on to Andrew;
> > meanwhile, Joe sends another patch to l-k and Peter forwards it on to
> > Andrew.  Andrew integrates both patches, as well as several unrelated
> > bits he creates himself, into -mm77, which he sends to Linus and gets
> > integrated.
> 
> But -mm is actually maintained as a serial set of patches, each
> submitted independently. Occassionally patches are rolled together
> here, but that's the exception.

Well, -mm might be okay, but you force everyone to work like that.

> The case I'm still worried about is something like a filesystem that
> gets worked on out-of-tree for an extended period of time and gets
> submitted in a lump. If it's developed inside the confines of a
> corporation, sure, it can be signed off by one person in authority,
> but if it's developed in the open with numerous outside submissions,
> it's less clear what the right thing is. Aggregating 500
> signed-off-bys might get messy.

I really hope it is okay to just sign it off and take a blame.

Imagine more difficult scenario: tivo has kernel with about
1000 changes, and I have their vmlinux. At this point I can ask
them about source, and get it. Now I select 333 good patches...
I guess right thing here is to sign it off myself as I have got the
vmlinux?

I do not think that tivo/wlan vendors are going to do anything not forced
upon them by GPL, and I do not think GPL forces you to sign off...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [RFD] Explicitly documenting patch submission

[Shane Shrybman]

Hi Linus,

Since your intention is to produce a clearly documented path on where
each patch came from so that in the event the "Crack Smokers" come at
you for "stealing" code you have something to back up the community's
claims of authorship. I am wondering if your proposal would be adequate
legal protection.

I am definitely not a lawyer, but it would be a tragedy if your proposal
was adopted and in 10-15 years it was challenged and found not "to hold
water" in the courts. I can just imagine some lawyer making an argument
that this documentation trail is digital and therefore could be altered
without leaving a trace or some other argument that lessens the
integrity and legal value of the patch path information. 

Have you consulted with some liars about the legal fortitude of your
proposal?

What sort of legal protection will this provide in the event that it is
needed?

Just a thought.

Regards,

Shane

Re: [RFD] Explicitly documenting patch submission

[Andi Kleen]

Linus Torvalds <torvalds@osdl.org> writes:

> Hola!
>
> This is a request for discussion..

What's not completely clear to me is how the Signed-off-by
header is related to this:

> 	Developer's Certificate of Origin 1.0
[...]

I assume you're not expecting that people actually print out and sign
this and send it somewhere?

You're just asking that they read it and confirm to the maintainer
that they did, right?

e.g. consider some first contributor sends a maintainer a patch to be
incorporated.  Do you expect people now to send them this
Certification of Origin back and ask "Do you agree to this?"  
and only add the patch after they sent back an email "Yes I agree to this"?

That sounds quite involved to me. I bet in some companies this 
Certificate would first be sent to the legal department for approval,
delaying the patch for a long time

Even without such an explicit agreement it could get quite
complicated to figure out what to put into the Signed-off-by
lines if they're not already there.

e.g. normally the maintainer would just answer "ok, looks good,
applied". Now they would need to ask "ok, did you write this. if not
through which hands did it pass"? and wait for a reply and then only
add the patch when you know whom to put into all these Signed-off-by
lines.

This is not unrealistic, For example for patches that are "official
projects" by someone it often happens that not the actual submitter
sends the patch, but his manager (often not even cc'ing the original
developer). In some cases companies even go through huge efforts to
keep the original developers secret (I won't give names here, but it
happens). That's of course not because they stole anything, but
because they have some silly NDAs in place regarding not giving out
names of partners they're talking to or they just don't want you to
learn too much about their internals.

I would have no problems with just putting a Signed-Off-By for me
and for the person who sent me the patch, but trying to find out
all the people through whose mailboxes the patch travelled earlier
is potentially quite a lot of work. I am not sure I really 
want to get into that business.

I also don't think it's realistic to expect that everybody who
submits patches will put in all the right Signed-Off-Bys on their own,
so requiring the full path would put the maintainers into the 
situation outlined above.

Just alone asking them to agree to the Certificate of Origin would 
be probably a lot of work.

I don't think any solution that requires significantly more work
on part of the maintainer will be a good idea.

-Andi

Re: [RFD] Explicitly documenting patch submission

[Davide Libenzi]

On Mon, 24 May 2004, Andi Kleen wrote:

> What's not completely clear to me is how the Signed-off-by
> header is related to this:
> 
> > 	Developer's Certificate of Origin 1.0
> [...]
> 
> I assume you're not expecting that people actually print out and sign
> this and send it somewhere?
> 
> You're just asking that they read it and confirm to the maintainer
> that they did, right?
> 
> e.g. consider some first contributor sends a maintainer a patch to be
> incorporated.  Do you expect people now to send them this
> Certification of Origin back and ask "Do you agree to this?"  
> and only add the patch after they sent back an email "Yes I agree to this"?
> 
> That sounds quite involved to me. I bet in some companies this 
> Certificate would first be sent to the legal department for approval,
> delaying the patch for a long time
> 
> Even without such an explicit agreement it could get quite
> complicated to figure out what to put into the Signed-off-by
> lines if they're not already there.
> 
> e.g. normally the maintainer would just answer "ok, looks good,
> applied". Now they would need to ask "ok, did you write this. if not
> through which hands did it pass"? and wait for a reply and then only
> add the patch when you know whom to put into all these Signed-off-by
> lines.

IANAL, but I don't think they have to ask. As with GPL, you not required 
to sign anything to be able to use the software. By using the software you 
agree on the license. By submitting a patch to a maintainer, you agree 
with the Developer's Certificate of Origin.



- Davide

Re: [RFD] Explicitly documenting patch submission

[Joe Perches]

On Mon, 2004-05-24 at 13:07, Davide Libenzi wrote:
> By submitting a patch to a maintainer, you agree 
> with the Developer's Certificate of Origin.

I rather doubt this myself.
If submitted via public list, then perhaps.
Otherwise?  perhaps not.

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Mon, 24 May 2004, Davide Libenzi wrote:
> 
> IANAL, but I don't think they have to ask. As with GPL, you not required 
> to sign anything to be able to use the software. By using the software you 
> agree on the license. By submitting a patch to a maintainer, you agree 
> with the Developer's Certificate of Origin.

No, the thing is, we want your name to show up, and we do want you to 
explicitly state that not only do you know about the license, you also 
have the right to release your code under the license.

Yes, that was all implied before. This is nothing new. The only new thing 
is to _document_ it, and make it _explicit_.

And that means that submitters should read the DCO, and add the extra 
line. That's kind of the whole point of it - making a very ingrained and 
implicit assumption be explicitly documented.

In other words: this is not about changing the way we work. It's about 
documenting the things we take for granted. So that outsiders can be shown 
how it works.

		Linus

Re: [RFD] Explicitly documenting patch submission

[Davide Libenzi]

On Mon, 24 May 2004, Linus Torvalds wrote:

> 
> 
> On Mon, 24 May 2004, Davide Libenzi wrote:
> > 
> > IANAL, but I don't think they have to ask. As with GPL, you not required 
> > to sign anything to be able to use the software. By using the software you 
> > agree on the license. By submitting a patch to a maintainer, you agree 
> > with the Developer's Certificate of Origin.
> 
> No, the thing is, we want your name to show up, and we do want you to 
> explicitly state that not only do you know about the license, you also 
> have the right to release your code under the license.
> 
> Yes, that was all implied before. This is nothing new. The only new thing 
> is to _document_ it, and make it _explicit_.
> 
> And that means that submitters should read the DCO, and add the extra 
> line. That's kind of the whole point of it - making a very ingrained and 
> implicit assumption be explicitly documented.
> 
> In other words: this is not about changing the way we work. It's about 
> documenting the things we take for granted. So that outsiders can be shown 
> how it works.

That was what I was implying. Example:

me: Andrew this is the quit-smoking-patch-0.1.diff
Andrew: Where's your signature? Go read Documentation/xxx and repost the signed version
me: Oke doke. Reading ...
me: There you go, here's quit-smoking-patch-0.2.diff with the required signature



- Davide

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Mon, 24 May 2004, Davide Libenzi wrote:
> 
> That was what I was implying. Example:
> 
> me: Andrew this is the quit-smoking-patch-0.1.diff
> Andrew: Where's your signature? Go read Documentation/xxx and repost the signed version
> me: Oke doke. Reading ...
> me: There you go, here's quit-smoking-patch-0.2.diff with the required signature

Yes. On the other hand, I'm really hoping that since the whole procedure
is so simple, after a few times this has happened, people will just do the
sign-off without even thinking about it. So the "come back with a
signed-off version" case hopoefully doesn't happen too much.

So we'll have it for a while (and I'll probably add a check to my "apply"
scripts to _check_ for the sign-off thing at least for anything bigger
than a few lines), but I'm _hoping_ that in half a year people will wonder 
why we even discussed this.

And I might be wrong. Maybe it's just going to be a constant irritant, and 
we'll have to just revisit the issue and decide that it was a stupid idea. 

			Linus

Re: [RFD] Explicitly documenting patch submission

[Francis J. A. Pinteric]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On Mon, 24 May 2004 13:45:33 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
>
> In other words: this is not about changing the way we work. It's about
> documenting the things we take for granted. So that outsiders can be
> shown how it works.
> 

Personally, I'd like to see this evolve into something along the lines
of ISO-9000. If linux development can have the ability to create
detailed audit trails of code changes there would never be a question
about who contributed what and who owns it.

It would be nice if some sort of ISO-9000 compliance were a long term
goal here. The proprietary software houses would go nuts.

>>>---fja->


-- 
If you think what I'm saying is "politically incorrect",
you've got the wrong politics.

Tired of `netiquette'? Fed up with endless discussion of
what is '[OT]'? Linux, Free/Open Source discussion without
the "political correctness:" http://linuxdoctor.dyndns.org/list.html


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFD] Explicitly documenting patch submission

[viro]

On Mon, May 24, 2004 at 08:41:55PM -0400, Francis J. A. Pinteric wrote:
 
> Personally, I'd like to see this evolve into something along the lines
> of ISO-9000. If linux development can have the ability to create
> detailed audit trails of code changes there would never be a question
> about who contributed what and who owns it.
> 
> It would be nice if some sort of ISO-9000 compliance were a long term
> goal here. The proprietary software houses would go nuts.

Why would we care whether they go nuts or not?  We would go nuts, now
_that_ I do care about.

> >>>---fja->
> 
> 
> -- 
> If you think what I'm saying is "politically incorrect",

No, just plain stupid.

> you've got the wrong politics.
>
> Tired of `netiquette'?

Not really.  *plonk*

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Mon, 24 May 2004, Andi Kleen wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > Hola!
> >
> > This is a request for discussion..
> 
> What's not completely clear to me is how the Signed-off-by
> header is related to this:
> 
> > 	Developer's Certificate of Origin 1.0
> [...]
> 
> I assume you're not expecting that people actually print out and sign
> this and send it somewhere?

No. 

> You're just asking that they read it and confirm to the maintainer
> that they did, right?

Right. We'd add it to the Documentation directory, and add pointers to it 
to anything that mentions the "Signed-off-by:" thing (eg things like 
SubmittingPatches). All just to make sure that people are aware of what it 
means to say "Signed-off-by:"

> That sounds quite involved to me. I bet in some companies this 
> Certificate would first be sent to the legal department for approval,
> delaying the patch for a long time

Having worked at a company like that, I can say that that is true pretty 
much regardless of what the patch submission is (it's about a million 
times _worse_ if you have something like the FSF copyright assignment 
thing, but it's certainly true even for random open source things that 
don't have the physical paperwork and copyright assignment).

> e.g. normally the maintainer would just answer "ok, looks good,
> applied". Now they would need to ask "ok, did you write this. if not
> through which hands did it pass"? and wait for a reply and then only
> add the patch when you know whom to put into all these Signed-off-by
> lines.

No. The point is that a maintainer does NOT need to do this, exactly 
because we'd try to educate people to have the "Signed-off-by:" line pass 
with the patch from the very beginning.

> This is not unrealistic, For example for patches that are "official
> projects" by someone it often happens that not the actual submitter
> sends the patch, but his manager (often not even cc'ing the original
> developer). In some cases companies even go through huge efforts to
> keep the original developers secret (I won't give names here, but it
> happens).

Absolutely. And the whole sign-off procedure is _designed_ for this. 

The person who signs off on a patch does not need to be the author: in 
fact at a company that has "release people", it's not _supposed_ to be the 
author, it's supposed to be the company release person (although the 
original author may well have signed off on it internally - but that's not 
somethign that an external maintainer would know about or even care 
about).

			Linus

Re: [RFD] Explicitly documenting patch submission

[Andi Kleen]

On Mon, May 24, 2004 at 01:31:49PM -0700, Linus Torvalds wrote:
> > You're just asking that they read it and confirm to the maintainer
> > that they did, right?
> 
> Right. We'd add it to the Documentation directory, and add pointers to it 
> to anything that mentions the "Signed-off-by:" thing (eg things like 
> SubmittingPatches). All just to make sure that people are aware of what it 
> means to say "Signed-off-by:"

Hmm, but it would still take a long time until everybody does this
by default (and there will be always people who don't read all
the instructions before sending a patch, so it's not that this will
stop at some point). Would you require maintainers
to reject patches when the signoff lines are missing?

I personally would hate to reject a value bug fix because of a policy
like this...

In practice I guess it would end up with that maintainers would spend a lot
of time explaining to everybody what this new policy is about and 
possibly are forced to reject a lot of patches initially. 

-Andi

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Mon, 25 May 2004, Andi Kleen wrote:
> 
> In practice I guess it would end up with that maintainers would spend a lot
> of time explaining to everybody what this new policy is about and 
> possibly are forced to reject a lot of patches initially. 

...which is why we want to have a wide discussion of it now, the less to 
have to explain to people ;)

I don't expect this process to start taking effect for a while. Not only 
do we need to come to some level of agreement about it, but we need to 
give people the time to learn about it _without_ rejecting patches in the 
meantime. 

There is no real "flag-day" (and it's certainly not today), although I'm
hoping that by the time I start up 2.7.x we'd have this in place.

		Linus

Re: [RFD] Explicitly documenting patch submission

[Thomas Gleixner]

On Monday 24 May 2004 21:57, Andi Kleen wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> > Hola!
> > This is a request for discussion..

> e.g. normally the maintainer would just answer "ok, looks good,
> applied". Now they would need to ask "ok, did you write this. if not
> through which hands did it pass"? and wait for a reply and then only
> add the patch when you know whom to put into all these Signed-off-by
> lines.

What I'm missing in this discussion is a clear distinction between patches and 
contributions.

A patch is usually a more or less small fix / improvement of existing code and 
should be treated accordingly. Recording "signed-off" chains for those would  
just using up repository space and could be used just for another type of 
useless statistics. 

Contributions are larger pieces of code introducing new functionalities or 
algorithms and contain probably stuff which could be classified as 
"Intellectual Property" and therefor Linus' proposal is surely appropriate.

I'm not sure how to distinguish exactly between patches and contributions, but 
I'm not convinced, that

- (if x > 0)
+ (if x >= 0)
signed-off hacker
signed-off module-maintainer
signed-off subsystem-maintainer
signed-off linus / andrea /...

would really be helpful and desired.

> This is not unrealistic, For example for patches that are "official
> projects" by someone it often happens that not the actual submitter
> sends the patch, but his manager (often not even cc'ing the original
> developer). ....

If the manager or who ever ensures by signing off that this code is according 
to the submission rules, then it should be sufficient for the maintainer.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Mon, 24 May 2004, Thomas Gleixner wrote:
> 
> What I'm missing in this discussion is a clear distinction between patches and 
> contributions.

Well, I'm not sure such a clear distinction exists.

Clearly there are patches that are so trivial that we simply don't care 
about the process, because they don't contain any "new work". Spelling 
fixes, and trivial one-liners.

On the other hand, I'd rather have the process be "we always have the 
sign-off", coupled with just plain common sense.

Any process that doesn't allow for common sense is just broken, and
clearly from a _legal_ standpoint it doesn't matter if we track who fixed
out (atrocious) spelling errors.

On the other hand, it if becomes a habit, and we just sign-off even on the 
trivial stuff, that's actually going to make the whole process a lot 
easier - simply by avoiding the bother of even having to think about it.

So I'd rather encourage people to sign off on even the silly stuff, than 
to have to constantly make a judgement call. At the same time, I think 
that if somebody _didn't_ sign off on the simple stuff, we shouldn't just 
run around in circles like hens in a hen-house, we should just say "hey, 
we've got brains, the process isn't meant to be _stupid_".

			Linus

Re: [RFD] Explicitly documenting patch submission

[Thomas Gleixner]

On Monday 24 May 2004 23:05, Linus Torvalds wrote:
> On the other hand, I'd rather have the process be "we always have the
> sign-off", coupled with just plain common sense.

Makes sense

> So I'd rather encourage people to sign off on even the silly stuff, than
> to have to constantly make a judgement call. At the same time, I think
> that if somebody _didn't_ sign off on the simple stuff, we shouldn't just
> run around in circles like hens in a hen-house, we should just say "hey,
> we've got brains, the process isn't meant to be _stupid_".

:)

One more practical point.

Module maintainers receive patches from various hackers and commit them after 
review with the appropriate "sign-offs" to a subsystem repository.

Subsystem maintainer makes his monthly / whatever upstream update. 

Until now he just reviews the total changes from his last update til now. To 
keep your proposed procedure consistent he would be forced now to go through 
the "trusted" step by step commitments of his module maintainers, extract the 
"sign-offs" and add his own "sign-off" to each single step before pushing the 
improvements upstream. 

IMHO it would suffice for this situation, if the "sign-offs" are tracked in 
the subsystem repository and the subsystem maintainer signs off for the 
overall patch / contribution which is sent upstream.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: [RFD] Explicitly documenting patch submission

[Pavel Machek]

Hi!

> > So I'd rather encourage people to sign off on even the silly stuff, than
> > to have to constantly make a judgement call. At the same time, I think
> > that if somebody _didn't_ sign off on the simple stuff, we shouldn't just
> > run around in circles like hens in a hen-house, we should just say "hey,
> > we've got brains, the process isn't meant to be _stupid_".
> 
> :)
> 
> One more practical point.
> 
> Module maintainers receive patches from various hackers and commit them after 
> review with the appropriate "sign-offs" to a subsystem repository.
> 
> Subsystem maintainer makes his monthly / whatever upstream update. 
> 
> Until now he just reviews the total changes from his last update til now. To 
> keep your proposed procedure consistent he would be forced now to go through 
> the "trusted" step by step commitments of his module maintainers, extract the 
> "sign-offs" and add his own "sign-off" to each single step before pushing the 
> improvements upstream. 
> 
> IMHO it would suffice for this situation, if the "sign-offs" are tracked in 
> the subsystem repository and the subsystem maintainer signs off for the 
> overall patch / contribution which is sent upstream.
> 

This is actually a problem. It forces subsystem maintainer
to have version control system and not to rm -rf it
when he needs disk space.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [RFD] Explicitly documenting patch submission

[Matt Mackall]

On Mon, May 24, 2004 at 02:05:40PM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 24 May 2004, Thomas Gleixner wrote:
> > 
> > What I'm missing in this discussion is a clear distinction between patches and 
> > contributions.
> 
> Well, I'm not sure such a clear distinction exists.

Actually, there is a question as to how to sign off on something that
eventually gets rolled into something larger? Simply collect all the
signatories? Andrew aggregates patches on a fairly regular basis. How
about stuff that gets merged from the CVS trees of public projects? I
think we need a way to say "this came from an aggregate external
source" for patches that aren't simply passed along one by one.
Perhaps something like:

Signed-off-by: J Random hacker <foo@bar.com> from http://baz.sourceforge.net

> Any process that doesn't allow for common sense is just broken, and
> clearly from a _legal_ standpoint it doesn't matter if we track who fixed
> out (atrocious) spelling errors.

"our"

-- 
Mathematics is the supreme nostalgia of our time.

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Mon, 24 May 2004, Matt Mackall wrote:
> 
> Actually, there is a question as to how to sign off on something that
> eventually gets rolled into something larger? Simply collect all the
> signatories?

Yup.

This is indeed common for people like Andrew (or anybody else who collects 
patches). The only sane thing to do is to just merge the signatories from 
any merged patches.

> > Any process that doesn't allow for common sense is just broken, and
> > clearly from a _legal_ standpoint it doesn't matter if we track who fixed
> > out (atrocious) spelling errors.
> 
> "our"

Ahem.

"I did that on purpose to make a point".

Sure, that's the ticket.

		Linus "ehh, good save" Torvalds

Re: [RFD] Explicitly documenting patch submission

[Giuseppe Bilotta]

Linus Torvalds wrote:
> > > Any process that doesn't allow for common sense is just broken, and
> > > clearly from a _legal_ standpoint it doesn't matter if we track who fixed
> > > out (atrocious) spelling errors.
> > 
> > "our"
> 
> Ahem.
> 
> "I did that on purpose to make a point".
> 
> Sure, that's the ticket.
> 
> 		Linus "ehh, good save" Torvalds

Maybe in English "fix out" is a phrasal verb? Uh? Can we make 
it up like that? Any native speaker?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: [RFD] Explicitly documenting patch submission

[Steven Cole]

On May 25, 2004, at 5:11 AM, Giuseppe Bilotta wrote:

> Linus Torvalds wrote:
>>>> Any process that doesn't allow for common sense is just broken, and
>>>> clearly from a _legal_ standpoint it doesn't matter if we track who 
>>>> fixed
>>>> out (atrocious) spelling errors.
>>>
>>> "our"
>>
>> Ahem.
>>
>> "I did that on purpose to make a point".
>>
>> Sure, that's the ticket.
>>
>> 		Linus "ehh, good save" Torvalds
>
> Maybe in English "fix out" is a phrasal verb? Uh? Can we make
> it up like that? Any native speaker?

To avoid being punched out, I plan on waiting until about a year
into the 2.7.x series before submitting patches (via the maintainers
this time) to change out the accumulating speling erors.  That
will hopefully* minimize conflict with the initial surge of patches
at the beginning and the stabilization period near the end.

*hopefully used as a sentence adverb.

	Steven

Re: [RFD] Explicitly documenting patch submission

[La Monte H.P. Yarroll]

Giuseppe Bilotta wrote:

>Linus Torvalds wrote:
>  
>
>>>>Any process that doesn't allow for common sense is just broken, and
>>>>clearly from a _legal_ standpoint it doesn't matter if we track who fixed
>>>>out (atrocious) spelling errors.
>>>>        
>>>>
>>>"our"
>>>      
>>>
>>Ahem.
>>
>>"I did that on purpose to make a point".
>>
>>Sure, that's the ticket.
>>
>>		Linus "ehh, good save" Torvalds
>>    
>>
>
>Maybe in English "fix out" is a phrasal verb? Uh? Can we make 
>it up like that? Any native speaker?
>  
>
It is now.  On behalf of native speakers of English I hereby welcome the 
phrasal verb
"fix out" to the language.  I even offer a defintion and an etymological 
reference:

fix out: To fix or repair by removing.  E.g. "It doesn't matter if we 
track who fixed
out spelling errors." (Torvalds, lkml,  2004)

See, it's official now.

-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig

Re: [RFD] Explicitly documenting patch submission

[Horst von Brand]

Andi Kleen <ak@muc.de> said:

[...]

> e.g. consider some first contributor sends a maintainer a patch to be
> incorporated.  Do you expect people now to send them this
> Certification of Origin back and ask "Do you agree to this?"  
> and only add the patch after they sent back an email "Yes I agree to
this"?

Yep. That's exactly the point: That they don't come back later and scream
they just patented the for loop, and that its inclusion wasn't legitimate.

> That sounds quite involved to me. I bet in some companies this 
> Certificate would first be sent to the legal department for approval,
> delaying the patch for a long time

Tough luck, IMEHO.

> Even without such an explicit agreement it could get quite
> complicated to figure out what to put into the Signed-off-by
> lines if they're not already there.
> 
> e.g. normally the maintainer would just answer "ok, looks good,
> applied". Now they would need to ask "ok, did you write this. if not
> through which hands did it pass"? and wait for a reply and then only
> add the patch when you know whom to put into all these Signed-off-by
> lines.

I'd hope this gets part of the normal patch flow sooner or later, so that
this will only have to be done on occasion.

> This is not unrealistic, For example for patches that are "official
> projects" by someone it often happens that not the actual submitter
> sends the patch, but his manager (often not even cc'ing the original
> developer). In some cases companies even go through huge efforts to
> keep the original developers secret (I won't give names here, but it
> happens). That's of course not because they stole anything, but
> because they have some silly NDAs in place regarding not giving out
> names of partners they're talking to or they just don't want you to
> learn too much about their internals.

What should be done is that Someone In Power signs off the patch(es)
contributed by said company. This is to have a way to trace to someone who
willingly (and taking responsibility) contributed each patch. Sure, it'd be
nice to also know who commited some heinous crime(s), but...

Remember, what Linus wants is that no onne can pull an SCOX on Linux: If
they come screaming that it contains preciousss IP, you can show in detail
where it came from and make sure it is legitimate (or whom to blame, as the
case may be).

> I would have no problems with just putting a Signed-Off-By for me
> and for the person who sent me the patch, but trying to find out
> all the people through whose mailboxes the patch travelled earlier
> is potentially quite a lot of work. I am not sure I really 
> want to get into that business.

What you should care about is that the next in line signed off their
contribution(s) or certifies the origin.

> I also don't think it's realistic to expect that everybody who
> submits patches will put in all the right Signed-Off-Bys on their own,
> so requiring the full path would put the maintainers into the 
> situation outlined above.

Much less hassle than FSF's paperwork, to be sure.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [RFD] Explicitly documenting patch submission

[Albert Cahalan]

[this didn't have the right subject before, sorry]

Linus Torvalds writes:

> (Seriously, while nobody has actually complained about
> the suggested rules, I don't think anybody should feel
> compelled to do the sign-off before we've had more
> time to let people argue over it. People who feel 
> comfortable with the suggestion are obviously
> encouraged to start asap, though).

I had been hoping someone had just forged your email
address. :-/  You're not known for bureaucracy.

The wordy mix-case aspect is kind of annoying, and for
all that we don't get to differentiate actions.
I count:

1. came up with the design ideas
2. wrote the original patch
3. reviewed and passed on
4. modified
5. blindly passed on

Maybe "blindly passed on" needs nothing. So I'm
thinking, if we must bother with all this...

designed:
authored:
reviewed:
modified:

Add "pirated:" if you like, so that searching for
pirated code is easier than checking the evil bit.

Re: [RFD] Explicitly documenting patch submission

[Linus Torvalds]

On Mon, 24 May 2004, Albert Cahalan wrote:
> 
> The wordy mix-case aspect is kind of annoying, and for
> all that we don't get to differentiate actions.

I actually really really don't want to differentiate actions. There's 
really no reason to try to separate things out, and quite often the 
actions are mixed anyway. Besides, if they all end up having the same 
technical meaning ("I have the right to pass on this patch") having 
separate flags is just sure to confuse the process.

So what I want is something _really_ simple. Something that is
unambigious, and cannot be confused with something else. And in
particular, I want that sign-off line to be "strange" enough that there is
no possibility of ever writing that line by mistake - so that it is clear 
that the only reason anybody would write something like "Signed-off-by:" 
is because it meant _that_ particular thing.

In contrast, your suggestion of "modified:" is something that people might 
actually write when they write a changelog entry. 

One reason for uniqueness is literally for automatic parsing - having 
scripts that pick up on this, and send ACK messages, or do statistics on 
who patches tend to go through etc etc. 

		Linus

Re: [RFD] Explicitly documenting patch submission

[Horst von Brand]

Linus Torvalds <torvalds@osdl.org> said:

[...]

> One reason for uniqueness is literally for automatic parsing - having 
> scripts that pick up on this, and send ACK messages, or do statistics on 
> who patches tend to go through etc etc. 

AFAIU, what you really want is to go back 20 years from now and say "See? 
Lines 257-300 of foo/bar.c were contributed originally by J. Random Hacker
(here his signoff), and then modified by Jane Random and George Hacker, and
Aunt Tillie's grandson looked it over and blessed it into the official
kernel (signoffs here). If you got a problem with that, go talk to them." 
(that is what SCOundrels would need in place to be discouraged, I'm
afraid...).

Problem with your proposal for this is that either you keep patches from
the source intact (i.e., a bunch of one-liners each signed off separately,
signed off each one by the maintainer, plus a patch by said maintainer to
beat it all into useable shape) or shift the burden of being able to say
later (even _much_ later) that the patch was the bundling and mangling of
the individual patches.

I.e., this is an idea which was perhaps more appropiate in the olden days
when there was no maintainer hierarchy in place yet...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [RFD] Explicitly documenting patch submission

[Kai Henningsen]

torvalds@osdl.org (Linus Torvalds)  wrote on 25.05.04 in <1ZBgK-68x-3@gated-at.bofh.it>:

> On Mon, 24 May 2004, Albert Cahalan wrote:
> >
> > The wordy mix-case aspect is kind of annoying, and for
> > all that we don't get to differentiate actions.
>
> I actually really really don't want to differentiate actions. There's
> really no reason to try to separate things out, and quite often the
> actions are mixed anyway. Besides, if they all end up having the same
> technical meaning ("I have the right to pass on this patch") having
> separate flags is just sure to confuse the process.
>
> So what I want is something _really_ simple. Something that is
> unambigious, and cannot be confused with something else. And in
> particular, I want that sign-off line to be "strange" enough that there is
> no possibility of ever writing that line by mistake - so that it is clear
> that the only reason anybody would write something like "Signed-off-by:"
> is because it meant _that_ particular thing.

So it might be wise to add something approximately like this:

  Signed-off-by: Random C Developer <rcd@example.net> For: Linux kernel

Sometimes, pieces wander from one project into another, and tracking that  
as well could possibly help.

MfG Kai

Re: [RFD] Explicitly documenting patch submission

[Justin Michael]

Linus Torvalds <torvalds@osdl.org> wrote:
 
> On Mon, 24 May 2004, Davide Libenzi wrote:
> > 
> > IANAL, but I don't think they have to ask. As with GPL, you not required 
> > to sign anything to be able to use the software. By using the software you 
> > agree on the license. By submitting a patch to a maintainer, you agree 
> > with the Developer's Certificate of Origin.

> No, the thing is, we want your name to show up, and we do want you to 
> explicitly state that not only do you know about the license, you also 
> have the right to release your code under the license.
 
May I suggest the tag be "DCO-signoff-by" to make it more clear what the 
tag indicates.

Justin

Re: [RFD] Explicitly documenting patch submission

[Larry McVoy]

I just read the whole thread and I can't help but wonder if you aren't
trying to solve the 5% problem while avoiding the 95% problem.  Right now,
because of how patches are fanned in through maintainers, lots and lots
of patches are going into the SCM system (BK and/or CVS since that is
derived from BK) as authored by a handful of people.  Just go look at
the stats: http://linux.bkbits.net:8080/linux-2.5/stats?nav=index.html
As productive as Andrew is I find it difficult to believe he has
personally authored more than 5000 patches.  He hasn't, he doesn't
pretend to have done so but we are not getting the authorship right.

Solve that problem and you are lightyears closer to having an audit trail.
You currently aren't recording the original author and you are trying
to record all the people who touched the patch along the way.  If you
can't get the easy part right what makes you think you are going to get
the hard part right?

Before the obligatory BK flames start up, note this is a problem that
you would have with any SCM system.  The problem has nothing to do with
which SCM system you use, it has to do with recording authorship.

I think it's great that you are looking for a better audit trail but
I think it is strange that you are trying to get a perfect audit trail
when you don't even have the basics in place.  What was it that you said,
"Perfect is the enemy of good", right?  In my opinion the 99% part of
the problem space is who wrote the patch, not who passed it on.  If, and
that's a big if, you get to the point where you have proper authorship
recorded and then you still want to record the path it took, that's a
different matter.  The way you are going about it I think you may end
up with nothing by trying to be so perfect.  If I'm wrong, what's wrong
with fixing things so that you get the authorship right and then extend
to get the full path right?

This leaves aside the issue that patches can get applied multiple times
(and do all the time, I think we've counted thousands or tens of thousands
of this in the kernel history).

For what it is worth, we've actually thought through what you are trying
to do long ago and calculated the amount of metadata you'd end up carrying
around and found it to be way way way way too large for an SCM system to
justify.  It's unlikely we'd ever want full audit trails in BK because
patches tend to flow through multiple trees and get merged with other 
patches, etc.  The thing we found useful was who wrote the patch and in
what context.

We did change BK a few revs back to record both the importer and the
patch author when people use your import scripts (bk import -temail)
so we have a 2 deep audit trail already.  More than that seems like
overkill.

The more I think about it the more I wonder what problem it is you are 
trying to solve with the A->B->C->D->Linus audit trail.  Legally, the
issue is going to be with A more than anyone else.  What am I missing?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [RFD] Explicitly documenting patch submission

[Andrew Morton]

Larry McVoy <lm@bitmover.com> wrote:
>
> I just read the whole thread and I can't help but wonder if you aren't
> trying to solve the 5% problem while avoiding the 95% problem.  Right now,
> because of how patches are fanned in through maintainers, lots and lots
> of patches are going into the SCM system (BK and/or CVS since that is
> derived from BK) as authored by a handful of people.  Just go look at
> the stats: http://linux.bkbits.net:8080/linux-2.5/stats?nav=index.html
> As productive as Andrew is I find it difficult to believe he has
> personally authored more than 5000 patches.  He hasn't, he doesn't
> pretend to have done so but we are not getting the authorship right.

Numerous people have asked Linus to make that small change to his scripts
but he prefers it the way it is, because the current practice better
represents how the patch got into the tree.  The authors names are in the
changelog and the submitter's name is in the SCM metadata.

The scripts which Linus uses to generate the kernel release announcements
do fish inside the changelog and do accurately represent who-did-what.

Once the Signed-off-by: thing is fully underway perhaps he'll change this,
I don't know.

The problem is that the question "how did this code get into the tree" is
usually different from "who wrote that code".  And Linus values the former.

> You currently aren't recording the original author

We are, with care.  It's in the changelogs.  Every single patch which I
didn't originate has a From: line at the start of the changelog.

> and you are trying
> to record all the people who touched the patch along the way.  If you
> can't get the easy part right what makes you think you are going to get
> the hard part right?

We've got it as Linus wants it.

If you want to enhance BK to parse the Signed-off-by: stuff, or to embed it
in some manner as a first-class thing then that'd be neat, but parsing the
changelogs will suffice I expect.

> ...
> I think it's great that you are looking for a better audit trail but
> I think it is strange that you are trying to get a perfect audit trail
> when you don't even have the basics in place.

Disagree.  When multiple people work on a patch their identities are
already captured.  The Signed-off-by: stuff changes the format and
formalises it a bit.

What we're not capturing fully is who-did-what amongst the multiple
authors, unless that is specifically itemised in the changelog.

What also tends to not be captured is that in a quite large percentage of
cases I've diddled people's patches on the way through - bugfixes,
cleanups, spelling fixes and very frequent changelog improvements.  I'll
sometimes mention that in the changelog but usually don't bother.

A purist would say "that should have been a separate changeset" but I
disagree - I'd prefer that the patch which hits the tree is a single,
complete, logical whole.  Because the quality and integrity of the
changeset is more important than precisely tracking the little fixes which
got added on the way through.

Re: [RFD] Explicitly documenting patch submission

[Larry McVoy]

On Thu, May 27, 2004 at 01:04:09AM -0700, Andrew Morton wrote:
> Larry McVoy <lm@bitmover.com> wrote:
> >
> > I just read the whole thread and I can't help but wonder if you aren't
> > trying to solve the 5% problem while avoiding the 95% problem.  Right now,
> > because of how patches are fanned in through maintainers, lots and lots
> > of patches are going into the SCM system (BK and/or CVS since that is
> > derived from BK) as authored by a handful of people.  Just go look at
> > the stats: http://linux.bkbits.net:8080/linux-2.5/stats?nav=index.html
> > As productive as Andrew is I find it difficult to believe he has
> > personally authored more than 5000 patches.  He hasn't, he doesn't
> > pretend to have done so but we are not getting the authorship right.
> 
> Numerous people have asked Linus to make that small change to his scripts
> but he prefers it the way it is, because the current practice better
> represents how the patch got into the tree.  The authors names are in the
> changelog and the submitter's name is in the SCM metadata.

That means that all the SCM tools, BK, CVS, whatever, get the wrong attribution
when you are trying to track down a bug.  Which is more important when you are
debugging: knowing who created the change or who pushed the change to Linus?

The high order bit, in my not humble opinion, is the author.  If Linus wants
to keep the info about the submitter then do that in the check in comments.

> A purist would say "that should have been a separate changeset" but I
> disagree - I'd prefer that the patch which hits the tree is a single,
> complete, logical whole.  Because the quality and integrity of the
> changeset is more important than precisely tracking the little fixes which
> got added on the way through.

I think we can have our cake and eat it too, at least in BK (and there
is no reason other systems couldn't do this as well):  BK does not have
the concept of a 1:1 binding between a change to a file and a changeset.
A changeset is a container which may have one or more deltas to one or
more files, i.e., it is many:1.

If you took to sending your patches as the original patch plus another
patch, bundling them together (I can work out a format and GPLed tools for
this) then what we could do is have the BK import tools record the first
one as a set of deltas, the next one as another set of deltas, and so on.
We can handle an arbitrary number of patches to patches to patches.
Then when the import finishes we bundle up all the deltas in one logical
changeset.  99% of the time people won't care about the details, when
they are looking through the code the interfaces will all work as they
do today, the BK/Web interface would export this as a patch just like
you are used to, but when people do care the full information is there.

I suspect that with a little practice this could be quite useful.  
I could build tools which record the secondary patches as diffs to
the patches (I think) and if you have ever read a diff of a diff 
it is suprisingly useful.  I tend to save diffs of my work in 
progress and then later I'll generate diffs again and diff them to 
get my context back.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [RFD] Explicitly documenting patch submission

[Jörn Engel]

On Thu, 27 May 2004 07:51:27 -0700, Larry McVoy wrote:
> 
> I think we can have our cake and eat it too, at least in BK (and there
> is no reason other systems couldn't do this as well):  BK does not have
> the concept of a 1:1 binding between a change to a file and a changeset.
> A changeset is a container which may have one or more deltas to one or
> more files, i.e., it is many:1.
> 
> If you took to sending your patches as the original patch plus another
> patch, bundling them together (I can work out a format and GPLed tools for
> this) then what we could do is have the BK import tools record the first
> one as a set of deltas, the next one as another set of deltas, and so on.
> We can handle an arbitrary number of patches to patches to patches.
> Then when the import finishes we bundle up all the deltas in one logical
> changeset.  99% of the time people won't care about the details, when
> they are looking through the code the interfaces will all work as they
> do today, the BK/Web interface would export this as a patch just like
> you are used to, but when people do care the full information is there.

Sounds good, as long as it is simple (read: simplest) to read and
export the result of everything as one patch.  I.e. I wouldn't want to
see this:

@@ -28,6 +28,7 @@
 
 
 
+	/* new comment in empty raea */
 
 
 
@@ -28,67+28,7 @@
 
 
 
-	/* new comment in empty raea */
+	/* new comment in empty area */
 
 
 

But that goes without saying, doesn't it? ;)

> I suspect that with a little practice this could be quite useful.  
> I could build tools which record the secondary patches as diffs to
> the patches (I think) and if you have ever read a diff of a diff 
> it is suprisingly useful.  I tend to save diffs of my work in 
> progress and then later I'll generate diffs again and diff them to 
> get my context back.

Diffs to diffs I am even less eager to read.  As an internal format,
they make sense, though.

Jörn

-- 
There's nothing better for promoting creativity in a medium than
making an audience feel "Hmm ­ I could do better than that!"
-- Douglas Adams in a slashdot interview

Re: [RFD] Explicitly documenting patch submission

[Jon Smirl]

On Thu, 27 May 2004 07:51:27 -0700, Larry McVoy wrote:
> I suspect that with a little practice this could be quite useful.  
> I could build tools which record the secondary patches as diffs to
> the patches (I think) and if you have ever read a diff of a diff 
> it is suprisingly useful.  I tend to save diffs of my work in 
> progress and then later I'll generate diffs again and diff them to 
> get my context back.

This is a classic case of wanting an audit trail just like you have in
accounting packages. For audit trails you have to have the entire trail,
not just pieces of it. 

I like the idea of nested packages signed by each person who touched it.
The gives a perfect audit trail back to who authored each line. I'm sure
bk could be modified to produce these automatically.

I don't believe the size of this would get out of control. Only the master
Linux repository has to keep all of it. bk clone could get a new option
that says, i don't care about the downstream audit trail. Disks are cheap,
I doubt if the entire Linux audit trail would fill up more than a couple
of them.

Audit trails are something that are rarely looked at but of vital
importance. Linux needs complete and accurate audit trails. I agree that
audit trails can clutter up patches, but the patches have to have these
trails. The way to address this is via tools that convert the new patches
into the old formats for people to read. Plus the bitkeeper interface
would also hide all of the detail unless asked. Of course other source
control systems will also need a set of helper tools too.

Another problem is that you need a central key repository. Since it's
pretty stupid to for each developer to send $2,000 to verisign for a key
maybe bitmover would consider running the key repository. This is a
painful job, if they want to do it, I'd let them.


Jon Smirl, jonsmirl@yahoo.com

Re: [RFD] Explicitly documenting patch submission

[La Monte H.P. Yarroll]

Andrew Morton wrote:

>Larry McVoy <lm@bitmover.com> wrote:
>  
>
>>You currently aren't recording the original author
>>    
>>
>
>We are, with care.  It's in the changelogs.  Every single patch which I
>didn't originate has a From: line at the start of the changelog.
>
For patches that I've been involved with, the changelog line almost always
mentions one of the intermediate handlers, not the original author.  I 
suspect
that Larry is mostly right.

-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig

Re: [RFD] Explicitly documenting patch submission

[Theodore Ts'o]

On Thu, May 27, 2004 at 05:09:48PM -0400, La Monte H.P. Yarroll wrote:
> >We are, with care.  It's in the changelogs.  Every single patch which I
> >didn't originate has a From: line at the start of the changelog.
> >
> For patches that I've been involved with, the changelog line almost always
> mentions one of the intermediate handlers, not the original author.  I 
> suspect that Larry is mostly right.

Up until recently we've had the person doing the BK commit, plus
person they received it from.  That's identical to the two-level chain
of custody which Larry was proposing as being "good enough" most of
the time.  But more recently, there have been changelog comments like
this:

ChangeSet@1.1743.1.52, 2004-05-25 08:43:49-07:00, akpm@osdl.org
  [PATCH] minor sched.c cleanup

  Signed-off-by: Christian Meder <chris@onestepahead.de>
  Signed-off-by: Ingo Molnar <mingo@elte.hu>

  The following obviously correct patch from Christian Meder simplifies the
  DELTA() define.

Which do show the original author.  

						- Ted

Re: [RFD] Explicitly documenting patch submission

[Larry McVoy]

> ChangeSet@1.1743.1.52, 2004-05-25 08:43:49-07:00, akpm@osdl.org
>   [PATCH] minor sched.c cleanup
> 
>   Signed-off-by: Christian Meder <chris@onestepahead.de>
>   Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
>   The following obviously correct patch from Christian Meder simplifies the
>   DELTA() define.
> 
> Which do show the original author.  

Not in any useful way.  If I go look at the file history, which is what
I'm going to do when tracking down a bug, all I see on the files included
in this changeset is akpm@osdl.org.

That means any annotated listing (BK or CVS blame) shows the wrong author.

ChangeSet@1.1743.2.52, 2004-05-25 08:43:49-07:00, akpm@osdl.org +1 -0
  [PATCH] minor sched.c cleanup
  
  Signed-off-by: Christian Meder <chris@onestepahead.de>
  Signed-off-by: Ingo Molnar <mingo@elte.hu>
  
  The following obviously correct patch from Christian Meder simplifies the
  DELTA() define.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  kernel/sched.c@1.302, 2004-05-25 02:58:45-07:00, akpm@osdl.org +1 -2
    minor sched.c cleanup
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [RFD] Explicitly documenting patch submission

[Theodore Ts'o]

On Fri, May 28, 2004 at 06:24:36AM -0700, Larry McVoy wrote:
> Not in any useful way.  If I go look at the file history, which is what
> I'm going to do when tracking down a bug, all I see on the files included
> in this changeset is akpm@osdl.org.
> 
> That means any annotated listing (BK or CVS blame) shows the wrong author.

One of the ways that I often use for tracking down potential fixes is
to simply do "bk changes > /tmp/foo" and then use emacs's incremental
search to look for interesting potential changes.  (I know, you're
probably throwing up all over your keyboard just about now.  :-)

One "interesting" thing I've wished for is to be able to do "bk
revtool drivers/net/wireless/airo.c", and then when I put my mouse
over a particular line number, have it display in a little popup box 
the changelog description of whatever line my mouse happened to 
be over.  It would be a real pain to try to implement that in tcl/Tk, 
though....  that would make it easier to solve the specific problem
you've mentioned of "bk blame" showing the wrong author when looking 
at a particular source file.

						- Ted

Re: [RFD] Explicitly documenting patch submission

[Dave Jones]

On Fri, May 28, 2004 at 11:07:40AM -0400, Theodore Ts'o wrote:
 > On Fri, May 28, 2004 at 06:24:36AM -0700, Larry McVoy wrote:
 > > Not in any useful way.  If I go look at the file history, which is what
 > > I'm going to do when tracking down a bug, all I see on the files included
 > > in this changeset is akpm@osdl.org.
 > > 
 > > That means any annotated listing (BK or CVS blame) shows the wrong author.
 > 
 > One of the ways that I often use for tracking down potential fixes is
 > to simply do "bk changes > /tmp/foo" and then use emacs's incremental
 > search to look for interesting potential changes.  (I know, you're
 > probably throwing up all over your keyboard just about now.  :-)
 > 
 > One "interesting" thing I've wished for is to be able to do "bk
 > revtool drivers/net/wireless/airo.c", and then when I put my mouse
 > over a particular line number, have it display in a little popup box 
 > the changelog description of whatever line my mouse happened to 
 > be over.

bk revtool $filename
ctrl-c in the gui that pops up
click line that looks interesting - jumps to the cset with
commit comments.

That what you meant ?

		Dave

Re: [RFD] Explicitly documenting patch submission

[Larry McVoy]

> bk revtool $filename
> ctrl-c in the gui that pops up

That's just "c", Ctrl-c just happens to work and is not supported.  And
"c" is a very funny listing, it's rare that that is what you want.
I suspect what you want is to click the last node and then hit "a".

> click line that looks interesting - jumps to the cset with
> commit comments.

double click.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [RFD] Explicitly documenting patch submission

[Dave Jones]

On Fri, May 28, 2004 at 08:27:30AM -0700, Larry McVoy wrote:
 > > bk revtool $filename
 > > ctrl-c in the gui that pops up
 > 
 > That's just "c", Ctrl-c just happens to work and is not supported.  And
 > "c" is a very funny listing, it's rare that that is what you want.
 > I suspect what you want is to click the last node and then hit "a".

Ah, I found this by accident 8-)

 > > click line that looks interesting - jumps to the cset with
 > > commit comments.
 > double click.
 
ah, for full comments, yes.

		Dave

Re: [RFD] Explicitly documenting patch submission

[Theodore Ts'o]

On Fri, May 28, 2004 at 04:19:19PM +0100, Dave Jones wrote:
> bk revtool $filename
> ctrl-c in the gui that pops up
> click line that looks interesting - jumps to the cset with
> commit comments.
> 
> That what you meant ?

Yes, except you have to type all of the extra characters, and manually
dismiss the window after looking at the comments.  I was looking for
something where the window pops up automatically when you mouse over
the line number, and disappear when you move the mouse away.  (This is
not new; a number of modern GUI interfaces have this style of
interface).

On Fri, May 28, 2004 at 08:24:50AM -0700, Larry McVoy wrote:
> We already have that implemented in some tree somewhere, I think one of
> the commercial branches.  It's not hard at all, but it's fairly slow
> because it has to go pawing through the ChangeSet file.  Yeah, we could
> add a cache but it seems rather pointless.

How slow could it be on a 1.6 GHz Pentium-M with 2 gigs of memory?  :-)

All other BK operations tend to fly when everything is in the page cache.
<grin>

> It is simply better to have the correct information recorded in the
> correct place.  Saying that you can go dig it out of the ChangeSet file is
> self defeating, that sucker is 40MB and digging anything out of it hurts.

I agree with you, but that decision isn't up to me.  So I (and all of
us) have to make the best with what the Big Penguin has decided....

A compromise position might be to store multiple authorships (who
committed it into BK, who was the original author, etc.) into the SCM
metadata, but I'm not sure we could justify your putting that kind
feature into BK, especially when it's likely that the only users of it
would be the Linux kernel tree.

							- Ted

Re: [RFD] Explicitly documenting patch submission

[Larry McVoy]

> A compromise position might be to store multiple authorships (who
> committed it into BK, who was the original author, etc.) into the SCM
> metadata, but I'm not sure we could justify your putting that kind
> feature into BK, especially when it's likely that the only users of it
> would be the Linux kernel tree.

We're always open to adding new features but we're not going to code around
delibrate misuse of the system.  We wouldn't be doing you any favors by 
doing so.  If you ever migrate off of BK then you'll need the next system
to have those same workarounds.

Go educate Linus that he got this one wrong, he's a reasonable guy, he
listens if enough people scream.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [RFD] Explicitly documenting patch submission

[Larry McVoy]

On Fri, May 28, 2004 at 11:07:40AM -0400, Theodore Ts'o wrote:
> On Fri, May 28, 2004 at 06:24:36AM -0700, Larry McVoy wrote:
> > Not in any useful way.  If I go look at the file history, which is what
> > I'm going to do when tracking down a bug, all I see on the files included
> > in this changeset is akpm@osdl.org.
> > 
> > That means any annotated listing (BK or CVS blame) shows the wrong author.
> 
> One of the ways that I often use for tracking down potential fixes is
> to simply do "bk changes > /tmp/foo" and then use emacs's incremental
> search to look for interesting potential changes.  (I know, you're
> probably throwing up all over your keyboard just about now.  :-)

Hey, whatever works for you.

> One "interesting" thing I've wished for is to be able to do "bk
> revtool drivers/net/wireless/airo.c", and then when I put my mouse
> over a particular line number, have it display in a little popup box 
> the changelog description of whatever line my mouse happened to 
> be over.  It would be a real pain to try to implement that in tcl/Tk, 
> though....  

We already have that implemented in some tree somewhere, I think one of
the commercial branches.  It's not hard at all, but it's fairly slow
because it has to go pawing through the ChangeSet file.  Yeah, we could
add a cache but it seems rather pointless.

It is simply better to have the correct information recorded in the
correct place.  Saying that you can go dig it out of the ChangeSet file is
self defeating, that sucker is 40MB and digging anything out of it hurts.
So even if we gave you this feature in revtool, which is just

	bk sccslog -r`bk r2c -r$REV $FILE` $FILE

it's going to be too slow to be useful.

I dunno what to tell you other than I'm trying to guide you towards the 
use of the SCM that will be productive for you.  This would be true in
CVS as well, except it is worse unless you are using the bk2cvs tree
which maintains the backpointer to the changeset file there.

Why people persist in storing the less used information cheaply and the
commonly used information expensively is beyond me.  But hey, it's your
source base, knock yourself out.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [RFD] Explicitly documenting patch submission

[Len Brown]

On Sun, 2004-05-23 at 11:38, Ian Stirling wrote:

> Has anyone ever tried to forge the name on a patch, and get it
> included?

Yes.

Today akpm send me a little patch via e-mail, I did this:

$ bk import -temail < akpm.email

This records the author as akpm -- not me.
I did a "bk comments" to clean up the comments,
but the author remains akpm, who included a
single "Signed-off-by: Andrew Morton <akpm@osdl.org>"

If you paw through the s-file, you'll find a little [lenb]
that shows I checked in the file -- but the tools don't
seem to show that.  You'll also see a little [torvalds]
on lots of akpm csets, so I guess Linus does the
same thing.

There is a clear audit trail that the csets came from
my repo: http://lkml.org/lkml/2004/5/3/77
Though I guess pawing through LKML archives to follow
patch origin should be an exception rather than a rule.

More often I apply a patch with "bk import -tpatch".
Here I get recorded as the one who checked-in,
so if the author was not me, I credit the author
in the check-in comments.  But I suppose that
here too I'm a forger b/c I use BK_USER=len.brown
so that the history records my valid company
e-mail address, rather than the userid [lenb]
I've got on my local development box.

I guess this second method is consistent with Linus'
proposal -- though I would have expected the first
method to be preferable -- at least for well-known
authors.

Also, I guess the news here is that sometimes the
last two levels of the check-in chain are automatically
recorded, but this is not well known.

cheers,
-Len