Date: Sun, 23 May 2004 06:48:09 GMT From: Linus Torvalds <torvalds@osdl.org> To: Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: [RFD] Explicitly documenting patch submission
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
Yes, and I can't see nothing wrong here. Unified desktop is just what many people want. Why not using Mozilla if it's better than Konqueror? Surrival of the fittest applies to software too, especially in free software.
Slashdot Mirror
Sure, all Linux users love Adobe's proprietary crap.
Linus has already acted.
Date: Sun, 23 May 2004 06:48:09 GMT
From: Linus Torvalds <torvalds@osdl.org>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [RFD] Explicitly documenting patch submission
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
I guess AmigaOS will still ignore MMU. With proper memory management Amiga would still rule. ;-)
See: 3Dwm
Yes.
Do you really think that they even have 'fix up security' on their TO DO list? ;-)
Hacker is not right word for criminals, they don't deserve that.
echo 'Red Hat' | sed 's/Red Hat/Mandrake/g'
I guess next George Lucas will invite Bill to be Darth Vader for "services to the universe."
err, you mean stupid?
Depenguinator "Upgrades" Linux to BSD http://bsd.slashdot.org/bsd/03/12/30/132225.shtml
I am sure that SCO shutdown Dennis' website as his license to UNIX has been revoked.
I like Postfix and SpamAssassin: http://cs.stadia.fi/~pkoistin/setting_up_spamassas sin_with_postfix.shtml
Dr. Evil says: "one million lines of UNIX System V protected code"
Those screenshot shows me a system that it's even harder to use than the current one.
Why do you have re-invent whell always?
Current configuration system is under change on 2.5.x series, anyway and already.
Here is my very effective (IMHO) Postfix spam filter to be added on /etc/postfix/main.cf file.
. txt
http://cs.stadia.fi/~pkoistin/postfix-spam-filter
NO WARRANTY!
Yes, and I can't see nothing wrong here. Unified desktop is just what many people want. Why not using Mozilla if it's better than Konqueror? Surrival of the fittest applies to software too, especially in free software.
If hacking is a crime then submitting patches to Linux is crime.
I belive terrorists rather crack that box rather than hack it.
Simple rule of the thumb:
- Hacking is legal, it's done by hackers.
- Cracking is illegal, it's done by crackers.
I hope some journalist readsPlease note that patent is issued on October 6, 1987. People didn't talk that much about software patents back then, I guess.