[PATCH] Cleanups for HOWTO do Linux kernel development

I hope you don't mind, I put on my Technical Editor hat
for a moment and came up with the following patch for:

- some grammar fixes (commas, etc)
- some clarity fixes - mostly style
- spelling
- consistency (api vs API, eg)

1 files changed, 35 insertions, 30 deletions

diff --git a/HOWTO b/HOWTO
index 68e018aa78fcc9..e0735ed38d57b2 100644
--- a/HOWTO
+++ b/HOWTO
@@ -20,7 +20,7 @@ know to achieve this by describing the process you need to go through,
 and hints on how to work with the community.  It will also try to
 explain some of the reasons why the community works like it does.
 
-The kernel is written mostly in C, with some architectural-dependent
+The kernel is written mostly in C, with some architecture-dependent
 parts written in assembly. A good understanding of C is required for
 kernel development. Assembly (any architecture) is not required unless
 you plan to do low-level development for that architecture. Though they
@@ -43,10 +43,10 @@ some information on them.
 Please remember that you are trying to learn how to work with the
 existing development community.  It is a very diverse group of people,
 with very high standards for coding, style and procedure.  These
-procedures have been created over time based on what they have found to
+standards have been created over time based on what they have found to
 work best for such a large and geographically dispersed team.  Try to
-learn as much as possible about these procedures ahead of time, as they
-are well documented, and do not expect people to adapt to you or your
+learn as much as possible about these standards ahead of time, as they
+are well documented; do not expect people to adapt to you or your
 company's way of doing things.
 
 
@@ -66,12 +66,12 @@ Documentation
 ------------
 
 The Linux kernel source tree has a large range of documents that are
-invaluable in learning how to interact with the kernel community.  When
+invaluable for learning how to interact with the kernel community.  When
 new features are added to the kernel, it is recommended that new
-documentation files are also added, that explain how to use the feature.
+documentation files are also added which explain how to use the feature.
 Here is a list of files that are in the kernel source tree that are
 required reading:
-  Documetation/CodingStyle
+  Documentation/CodingStyle
     This describes the Linux kernel coding style, and some of the
     rationale behind it. All new code is expected to follow the
     guidelines in this document. Most maintainers will only accept
@@ -86,7 +86,7 @@ required reading:
        - Email format
        - Who to send it to
     Following these rules will not guarantee success (as all patches are
-    subject to scrutiny of content and style), but not following them
+    subject to scrutiny for content and style), but not following them
     will almost always prevent it.
  
     Other excellent descriptions of how to create patches properly are:
@@ -125,13 +125,18 @@ required reading:
 
   Documentation/kernel-docs.txt
     A list of external documentation that pertains to kernel
-    development.  Please consult this list, if you do not find what you
+    development.  Please consult this list if you do not find what you
     are looking for within the in-kernel documentation.
 
+  Documentation/applying-patches.txt
+    A good introduction describing exactly what a patch is, how to
+    create it, and how to apply it to the different development branches
+    of the kernel.
+
 
 The kernel also has a large number of documents that can be
 automatically generated from the source code itself.  This includes a
-full description of the in-kernel api, and rules on how to handle
+full description of the in-kernel API, and rules on how to handle
 locking properly.  The documents will be created in the
 Documentation/DocBook/ directory and can be generated as PDF,
 Postscript, HTML, and man pages by running:
@@ -148,7 +153,7 @@ Becoming A Kernel Developer
 If you do not know anything about Linux kernel development, you should
 look at the Linux KernelNewbies project:
 	http://kernelnewbies.org
-It consists of a helpful mailing list, where you can ask almost any type
+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
@@ -156,22 +161,22 @@ real-time, and a lot of helpful documentation that is useful for
 learning about Linux kernel development.
 
 The website has basic information about code organization, subsystems,
-and current projects (both in-tree and out-of-tree). It also basic
-logistical information, like compiling a kernel and applying a patch.
+and current projects (both in-tree and out-of-tree). It also describes some 
+basic logistical information, like how to compile a kernel and apply a patch.
 
 If you do not know where you want to start, but you want to look for
 some task to start doing to join into the kernel development community,
 go to the Linux Kernel Janitor's project:
 	http://janitor.kernelnewbies.org/
 It is a great place to start.  It describes a list of relatively simple
-tasks that need to be cleaned up and fixed within the Linux kernel
+problems that need to be cleaned up and fixed within the Linux kernel
 source tree.  Working with the developers in charge of this project, you
 will learn the basics of getting your patch into the Linux kernel tree,
-and possibly point you in the direction of what to go work on next, if
+and possibly be pointed in the direction of what to go work on next, if
 you do not already have an idea.
 
 
-If you already have a chunk of code that you want to have go into the
+If you already have a chunk of code that you want to put into the
 kernel tree, but need some help getting it in the proper form, the
 kernel-mentors project was created to help you out with this.  It is a
 mailing list, and can be found at:
@@ -189,7 +194,7 @@ Mailing lists
 
 As some of the above documents describe, the majority of the core kernel
 developers participate on the Linux Kernel Mailing list.  Details on how
-to subscribe and unsubscribe from the list, can be found at:
+to subscribe and unsubscribe from the list can be found at:
 	http://vger.kernel.org/vger-lists.html#linux-kernel
 There are archives of the mailing list on the web in many different
 places.  Use a search engine to find these archives.  For example:
@@ -201,11 +206,11 @@ list archives.
 
 Most of the individual kernel subsystems also have their own separate
 mailing list where they do their development efforts.  See the
-MAINTAINERS file for a list of what these lists are, for the different
+MAINTAINERS file for a list of what these lists are for the different
 groups.
 
 Many of the lists are hosted on kernel.org. Information on them can be
-found here:
+found at:
 	http://vger.kernel.org/vger-lists.html
 
 Please remember to follow good behavioral habits when using the lists.
@@ -216,18 +221,18 @@ interacting with the list (or any list):
 If multiple people respond to your mail, the CC: list of recipients may
 get pretty large. Don't remove anybody from the CC: list without a good
 reason, or don't reply only to the list address. Get used to receiving the
-mail twice, one from the sender and the one from the list and don't try
+mail twice, one from the sender and the one from the list, and don't try
 to tune that by adding fancy mail-headers, people will not like it.
 
 Remember to keep the context and the attribution of your replies intact,
-keep the "John Kernelhacker wrote ...:" lines at the top of you reply and
+keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and
 add your statements between the individual quoted sections instead of
 writing at the top of the mail.
 
 If you add patches to your mail, make sure they are plain readable text
 as stated in Documentation/SubmittingPatches. Kernel developers don't
-want to deal with attachments or compressed patches, they may want
-to comment individual lines of your patch, which works only that way.
+want to deal with attachments or compressed patches; they may want
+to comment on individual lines of your patch, which works only that way.
 Make sure you use a mail program that does not mangle spaces and tab
 characters. A good first test is to send the mail to yourself and try
 to apply your own patch by yourself. If that doesn't work, get your
@@ -311,7 +316,7 @@ opinion have had positive experiences.  Here is a group that is a good
 starting point for women interested in contributing to Linux:
 	http://www.linuxchix.org/
 
-The language barrier can be present for some people who are not
+The language barrier can cause problems for some people who are not
 comfortable with English.  A good grasp of the language can be needed in
 order to get ideas across properly on mailing lists, so it is
 recommended that you check your emails to make sure they make sense in
@@ -324,7 +329,7 @@ Break your changes up
 The Linux kernel community does not gladly accept large chunks of code
 dropped on it all at once.  The changes need to be properly introduced,
 discussed, and broken up into tiny, individual portions.  This is almost
-exactly opposite of what companies are used to doing.  Your proposal
+the exact opposite of what companies are used to doing.  Your proposal
 should also be introduced very early in the development process, so that
 you can receive feedback on what you are doing.  It also lets the
 community feel that you are working with them, and not simply using them
@@ -337,12 +342,12 @@ The reasons for breaking things up are the following:
 1) Small patches increase the likelihood that your patches will be
    applied, since they don't take much time or effort to verify for
    correctness.  A 5 line patch can be applied by a maintainer with
-   barely a second glance. But, a 500 line patch may take hours to
+   barely a second glance. However, a 500 line patch may take hours to
    review for correctness (the time it takes is exponentially
    proportional to the size of the patch, or something).
 
    Small patches also make it very easy to debug when something goes
-   wrong.  It's much easier to back out patches one by one, than it is
+   wrong.  It's much easier to back out patches one by one than it is
    to dissect a very large patch after it's been applied (and broken
    something).
 
@@ -362,7 +367,7 @@ Here is an analogy from kernel developer Al Viro:
 	solution to the problem one is solving. They want to see a
 	simple and elegant solution."
 
-That may be challenging to keep the balance between presenting an elegant
+It may be challenging to keep the balance between presenting an elegant
 solution and working together with the community and discuss 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
@@ -402,8 +407,8 @@ ChangeLog section of the document:
 
 All of these things are sometimes very hard to do. It can take years to
 perfect these practices (if at all). It's a continuous process of
-improvement that requires a lot of patience and determination. But,
-don't give up. It's possible. Many have done it before, and each had to
+improvement that requires a lot of patience and determination. But
+don't give up, it's possible. Many have done it before, and each had to
 start exactly where you are now.