A few cleanups to SubmittingPatches:
- mention SubmitChecklist
- remove mention of my simple patch script tools
- remove last-updated line
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add desired 'diffstat' options to use for kernel patches.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
While looking for where to send trivial patches, I found old contact
information in Documentation/SubmittingPatches.
Signed-off-by: Kees Cook <kees@outflux.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Improve explanation of the Subject line fields in
Documentation/SubmittingPatches Canonical Patch Format.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Document more details of patch format such as the "from" line
and the "---" marker line, and provide more references for
patch guidelines.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Improve the likelihood that someone submitting a patch will notify the
MAN-PAGES maintainer.
This is a follow-up to comments on the July 29 lkml email thread: "Broke nice
range for RLIMIT NICE"
Signed-off-by: Paul Jackson <pj@sgi.com>
Cc: "Michael Kerrisk" <mtk-manpages@gmx.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Since the Trivial Patch Monkey is mentioned both in steps 4. and 5., I
removed it from step4 (Select e-mail destination), since it should go under
'Select your CC list'.
Signed-off-by: Cosmin Nicolaescu <cos@camelot.homelinux.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds a clause that notes explicitly that the person doing the
sign-off knows that the project (and his sign-off) is public and will
possibly get archived and re-distributed.
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Randy Dunlap