more copyedits from reviewers

1 files changed, 24 insertions, 24 deletions

diff --git a/HOWTO b/HOWTO
index ddb6e781b6aaa..fa07c28decfa1 100644
--- a/HOWTO
+++ b/HOWTO
@@ -110,12 +110,12 @@ required reading:
 
   Documentation/stable_api_nonsense.txt
     This file describes the rationale behind the conscious decision to
-    not have a stable API within the kernel, including for things like:
+    not have a stable API within the kernel, including things like:
       - Subsystem shim-layers (for compatibility?)
       - Driver portability between Operating Systems.
       - Mitigating rapid change within the kernel source tree (or
 	preventing rapid change)
-    This document is crucial for understand the Linux development
+    This document is crucial for understanding the Linux development
     philosophy and is very important for people moving to Linux from
     development on other Operating Systems.
 
@@ -167,7 +167,7 @@ look at the Linux KernelNewbies project:
 It consists of a helpful mailing list where you can ask almost any type
 of basic kernel development question (make sure to search the archives
 first, before asking something that has already been answered in the
-past.)  It also has a IRC channel that you can use to ask questions in
+past.)  It also has an IRC channel that you can use to ask questions in
 real-time, and a lot of helpful documentation that is useful for
 learning about Linux kernel development.
 
@@ -221,21 +221,21 @@ branches.  These different branches are:
 2.6.x kernels are maintained by Linus Torvalds, and can be found on
 kernel.org in the pub/linux/kernel/v2.6/ directory.  It's development
 process is as follows:
-  - As soon a new kernel is released a two weeks windows is open, during
-    this period of time maintainers can submit big diffs to Linus,
-    usually the patched sited in -mm kernels for a few weeks.  The
-    preferred way to submit big changes is using git (more information
-    about git can be found at http://git.or.cz/) but plain patches are
-    also just fine.
-  - After two weeks a -rc1 kernel is released and now is possible to
-    push only patches that do not include new features that could affect
-    the stability of the whole kernel.  Please note that a whole new
-    driver (or filesystem) might be accepted after -rc1 because there is
-    no risk of causing regressions with such a change as long as the
-    change is self-contained and does not affect areas outside of the
-    code that is being added.  git can be used to send patches to Linus
-    after -rc1 is released, but the patches need to also be sent to a
-    public mailing list for review.
+  - As soon as a new kernel is released a two weeks windows is open,
+    during this period of time maintainers can submit big diffs to
+    Linus, usually the patched sited in -mm kernels for a few weeks.
+    The preferred way to submit big changes is using git (more
+    information about git can be found at http://git.or.cz/) but plain
+    patches are also just fine.
+  - After two weeks a -rc1 kernel is released it is now possible to push
+    only patches that do not include new features that could affect the
+    stability of the whole kernel.  Please note that a whole new driver
+    (or filesystem) might be accepted after -rc1 because there is no
+    risk of causing regressions with such a change as long as the change
+    is self-contained and does not affect areas outside of the code that
+    is being added.  git can be used to send patches to Linus after -rc1
+    is released, but the patches need to also be sent to a public
+    mailing list for review.
   - A new -rc is released whenever Linus deems the current git (the
     kernel's source management) tree to be in a reasonably sane state
     adequate for testing.  The goal is to release a new -rc kernel every
@@ -243,7 +243,7 @@ process is as follows:
   - Process continues until the kernel is considered "ready", the
     process should last around 6 weeks.
 
-It is worth to mention what Andrew Morton wrote on the linux-kernel
+It is worth mentioning what Andrew Morton wrote on the linux-kernel
 mailing list about kernel releases:
 	"Nobody knows when a kernel will be released, because it's
 	released according to perceived bug status, not according to a
@@ -430,7 +430,7 @@ expecting?
   - criticism
   - comments
   - requests for change
-  - requests justification
+  - requests for justification
   - silence
 
 Remember, this is part of getting your patch into the kernel.  You have
@@ -549,7 +549,7 @@ Here is an analogy from kernel developer Al Viro:
 	simple and elegant solution."
 
 It may be challenging to keep the balance between presenting an elegant
-solution and working together with the community and discuss your
+solution and working together with the community and discussing your
 unfinished work. Therefore it is good to get early in the process to
 get feedback to improve your work, but also keep your changes in small
 chunks that they may get already accepted, even when your whole task is
@@ -579,7 +579,7 @@ all time.  It should describe the patch completely, containing:
   - implementation details
   - testing results
 
-For more details on what the this should all look like, please see the
+For more details on what this should all look like, please see the
 ChangeLog section of the document:
   "The Perfect Patch"
       http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
@@ -602,8 +602,8 @@ to be based on text he had written, and to Randy Dunlap and Gerrit
 Huizenga for some of the list of things you should and should not say.
 Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
 Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
-Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, and Alex Shepard for
-their review and comments on early drafts of this document.
+Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, and Alex
+Shepard for their review and comments on early drafts of this document.