[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 <ran...@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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Neil Brown
>
> 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 <ran...@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 <ran...@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 <ran...@developer.org> (certificate=1.0)
or maybe
Origin-certified-1.0-by: Random J Developer <ran...@developer.org>
Maybe I'm being too legalistic...
NeilBrown
Arjan van de Ven
> 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.
Greg KH
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
Arjan van de Ven
> 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.
Ian Stirling
> 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?
Greg KH
>
> 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.
Greg KH
>
> 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
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 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
Horst von Brand
> 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
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
Roman Zippel
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
Joe Perches
> 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.
Matt Mackall
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.
Jeff Garzik
> 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
Davide Libenzi
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
Joe Perches
> 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
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
Francois Romieu
[...]
> 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
Shane Shrybman
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
Daniel Phillips
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
Arjan van de Ven
> 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 <ran...@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.
Ben Collins
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/
ra...@themaw.net
> 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
Justin Michael
> 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
La Monte H.P. Yarroll
>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
Steven Cole
How about something like:
DCO 1.0 Signed-off-by: Random J Developer <ran...@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
La Monte H.P. Yarroll
>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 <ran...@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 <pi...@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
-
Bradley Hook
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 <ran...@developer.org>
And if they wanted to specify a version, use something like:
DCO-Sign-Off: Random J Developer <ran...@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 <pi...@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
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 <ran...@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 <pi...@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
La Monte H.P. Yarroll
>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 <ran...@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 <pi...@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
-
J. Bruce Fields
> 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
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
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
Valdis.K...@vt.edu
> 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....)
Ben Collins
>
>
> 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 <ji...@janitor.blah>
Signed-off-by: Ben Collins <bcol...@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/
Linus Torvalds
On Tue, 25 May 2004 Valdis.K...@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
Dave Jones
> 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 <ji...@janitor.blah>
> Signed-off-by: Ben Collins <bcol...@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 <da...@redhat.com>
Spotted-by: Joe Hacker <j...@scoblows.com>
As asking submitters to sign off on modified versions
of their patch would be silly overhead IMO.
Linus?
Dave
Andy Isaacson
> 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
Paul Jackson
> 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
"BettyC...@GeneralMills.com" pseudonym.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.650.933.1373
Ben Collins
> Spotted-by: Joe Hacker <j...@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/
La Monte H.P. Yarroll
Bradley Hook 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? 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
-
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
Bradley Hook
>
>>
>> recent published version unless specified. You could then shorten the
>> line to:
>>
>> DCO-Sign-Off: Random J Developer <ran...@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 <ran...@developer.org>
Come on now, get serious.
~Brad
Matt Mackall
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.
H. Peter Anvin
By author: "La Monte H.P. Yarroll" <pi...@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
Daniel Phillips
> 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
Larry McVoy
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
Andrew Morton
>
> 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.
Larry McVoy
> Larry McVoy <l...@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
Jörn Engel
>
> 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
Jon Smirl
> 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, jons...@yahoo.com
La Monte H.P. Yarroll
>Larry McVoy <l...@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
-
Theodore Ts'o
> >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:
Chan...@1.1743.1.52, 2004-05-25 08:43:49-07:00, ak...@osdl.org
[PATCH] minor sched.c cleanup
Signed-off-by: Christian Meder <ch...@onestepahead.de>
Signed-off-by: Ingo Molnar <mi...@elte.hu>
The following obviously correct patch from Christian Meder simplifies the
DELTA() define.
Which do show the original author.
- Ted
Larry McVoy
> [PATCH] minor sched.c cleanup
>
> Signed-off-by: Christian Meder <ch...@onestepahead.de>
> Signed-off-by: Ingo Molnar <mi...@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 ak...@osdl.org.
That means any annotated listing (BK or CVS blame) shows the wrong author.
Chan...@1.1743.2.52, 2004-05-25 08:43:49-07:00, ak...@osdl.org +1 -0
[PATCH] minor sched.c cleanup
Signed-off-by: Christian Meder <ch...@onestepahead.de>
Signed-off-by: Ingo Molnar <mi...@elte.hu>
The following obviously correct patch from Christian Meder simplifies the
DELTA() define.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
kernel/sch...@1.302, 2004-05-25 02:58:45-07:00, ak...@osdl.org +1 -2
minor sched.c cleanup
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
Theodore Ts'o
> 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 ak...@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
Dave Jones
> 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 ak...@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
Larry McVoy
> > 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 ak...@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
Larry McVoy
> 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
Dave Jones
> > 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
Theodore Ts'o
> 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
Larry McVoy
> 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
Pavel Machek
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