Re: [patch] Cleanups to Doc*/SubmittingPatches
From: Pavel Machek
Date: Sun May 14 2006 - 13:23:49 EST
> > This cleans up Submitting patches a bit. Missing/inconsistent full
> > stops, mostly.
> Incomplete sentences (fragments) don't need full stops, but they
> should be consistent.
> > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> > index c2c85bc..07b87ce 100644
> > --- a/Documentation/SubmittingPatches
> > +++ b/Documentation/SubmittingPatches
> > @@ -173,17 +173,17 @@ copy the maintainer when you change thei
> > For small patches you may want to CC the Trivial Patch Monkey
> > trivial@xxxxxxxxxx managed by Adrian Bunk; which collects "trivial"
> > patches. Trivial patches must qualify for one of the following rules:
> > - Spelling fixes in documentation
> > + Spelling fixes in documentation.
> > Spelling fixes which could break grep(1).
> I would just remove that '.' above and skip the rest of the
> changes in this section.
Does this look better? (Sorry, english is my 2nd language).
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c2c85bc..6f873e5 100644
@@ -174,15 +174,15 @@ For small patches you may want to CC the
trivial@xxxxxxxxxx managed by Adrian Bunk; which collects "trivial"
patches. Trivial patches must qualify for one of the following rules:
Spelling fixes in documentation
- Spelling fixes which could break grep(1).
+ Spelling fixes which could break grep(1)
Warning fixes (cluttering with useless warnings is bad)
Compilation fixes (only if they are actually correct)
Runtime fixes (only if they actually fix things)
- Removing use of deprecated functions/macros (eg. check_region).
+ Removing use of deprecated functions/macros (eg. check_region)
Contact detail and documentation fixes
Non-portable code replaced by portable code (even in arch-specific,
since people copy, as long as it's trivial)
- Any fix by the author/maintainer of the file. (ie. patch monkey
+ Any fix by the author/maintainer of the file (ie. patch monkey
in re-transmission mode)
@@ -246,13 +246,13 @@ updated change.
It is quite common for Linus to "drop" your patch without comment.
That's the nature of the system. If he drops your patch, it could be
-* Your patch did not apply cleanly to the latest kernel version
+* Your patch did not apply cleanly to the latest kernel version.
* Your patch was not sufficiently discussed on linux-kernel.
-* A style issue (see section 2),
-* An e-mail formatting issue (re-read this section)
-* A technical problem with your change
-* He gets tons of e-mail, and yours got lost in the shuffle
-* You are being annoying (See Figure 1)
+* A style issue (see section 2).
+* An e-mail formatting issue (re-read this section).
+* A technical problem with your change.
+* He gets tons of e-mail, and yours got lost in the shuffle.
+* You are being annoying.
When in doubt, solicit comments on linux-kernel mailing list.
@@ -475,22 +475,22 @@ SECTION 3 - REFERENCES
Andrew Morton, "The perfect patch" (tpp).
-Jeff Garzik, "Linux kernel patch submission format."
+Jeff Garzik, "Linux kernel patch submission format".
-Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer".
+Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
-NO!!!! No more huge patch bombs to linux-kernel@xxxxxxxxxxxxxxx people!.
+NO!!!! No more huge patch bombs to linux-kernel@xxxxxxxxxxxxxxx people!
-Linus Torvald's mail on the canonical patch format:
+Linus Torvalds's mail on the canonical patch format:
Last updated on 17 Nov 2005.
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/