Chapter cleanup:

- Various grammar fixes.
- Change "ie." to "i.e."
- Convert quotes to <quote> or other more appropriate tags.

PR:		docs/34967
Submitted by:	Ceri <setantae@submonkey.net>

en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml

@@ -30,7 +30,7 @@
     <para>The semantics of this are as follows:</para>
     
     <para>The maintainer owns and is responsible for that code.  This means
-      that he is responsible for fixing bugs and answer problem reports
+      that he is responsible for fixing bugs and answering problem reports
       pertaining to that piece of the code, and in the case of contributed
       software, for tracking new versions, as appropriate.</para>
 
@@ -100,7 +100,7 @@
       not applicable for FreeBSD can be removed.  In the case of Tcl, the
       <filename>mac</filename>, <filename>win</filename> and
       <filename>compat</filename> subdirectories were eliminated before the
-      import</para>
+      import.</para>
 
     <para><filename>src/lib/libtcl</filename> contains only a "bmake style"
       <filename>Makefile</filename> that uses the standard
@@ -118,7 +118,7 @@
 
     <para>The important thing here is that the
       <filename>src/contrib/tcl</filename> directory is created according to
-      the rules: It is supposed to contain the sources as distributed (on a
+      the rules: it is supposed to contain the sources as distributed (on a
       proper CVS vendor-branch and without RCS keyword expansion) with as few
       FreeBSD-specific changes as possible.  The 'easy-import' tool on
       freefall will assist in doing the import, but if there are any doubts on
@@ -131,7 +131,7 @@
       vendor branches, it is required that <quote>official</quote> patches from
       the vendor be applied to the original distributed sources and the result
       re-imported onto the vendor branch again.  Official patches should never
-      be patched into the FreeBSD checked out version and "committed", as this
+      be patched into the FreeBSD checked out version and <quote>committed</quote>, as this
       destroys the vendor branch coherency and makes importing future versions
       rather difficult as there will be conflicts.</para>
 
@@ -152,11 +152,11 @@
 
     <para>In the <filename>src/contrib/tcl</filename> level directory, a file
       called <filename>FREEBSD-upgrade</filename> should be added and it
-      should states things like:</para>
+      should state things like:</para>
     
     <itemizedlist>
       <listitem>
-	<para>Which files have been left out</para>
+	<para>Which files have been left out.</para>
       </listitem>
       
       <listitem>
@@ -165,7 +165,7 @@
       </listitem>
       
       <listitem>
-	<para>Where to send patches back to the original authors</para>
+	<para>Where to send patches back to the original authors.</para>
       </listitem>
       
       <listitem>
@@ -270,7 +270,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
       </listitem>
 
       <listitem>
-        <para>Kernel files;</para>
+        <para>Kernel files:</para>
 
         <orderedlist>
           <listitem>
@@ -294,7 +294,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
       </listitem>
 
       <listitem>
-        <para>User-land files;</para>
+        <para>User-land files:</para>
 
         <orderedlist>
           <listitem>
@@ -343,17 +343,17 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
     
     <para>For instance, added functions and bugfixes result in the minor
       version number being bumped, while deleted functions, changed function
-      call syntax etc.  will force the major version number to change.</para>
+      call syntax, etc. will force the major version number to change.</para>
     
     <para>Stick to version numbers of the form major.minor
       (<replaceable>x</replaceable>.<replaceable>y</replaceable>).  Our a.out
       dynamic linker does not handle version numbers of the form
       <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
       well.  Any version number after the <replaceable>y</replaceable>
-      (ie. the third digit) is totally ignored when comparing shared lib
+      (i.e. the third digit) is totally ignored when comparing shared lib
       version numbers to decide which library to link with.  Given two shared
       libraries that differ only in the <quote>micro</quote> revision,
-      <command>ld.so</command> will link with the higher one. Ie: if you link
+      <command>ld.so</command> will link with the higher one.  That is, if you link
       with <filename>libfoo.so.3.3.3</filename>, the linker only records
       <literal>3.3</literal> in the headers, and will link with anything
       starting with
@@ -363,7 +363,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
     
     <note>
       <para><command>ld.so</command> will always use the highest
-	<quote>minor</quote> revision.  Ie: it will use
+	<quote>minor</quote> revision.  For instance, it will use
 	<filename>libc.so.2.2</filename> in preference to
 	<filename>libc.so.2.0</filename>, even if the program was initially
 	linked with <filename>libc.so.2.0</filename>.</para>
@@ -371,13 +371,13 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
 
     <para>In addition, our ELF dynamic linker does not handle minor version
     numbers at all.  However, one should still specify a major and minor
-    version number as our <filename>Makefile</filename>s "do the right thing"
+    version number as our <filename>Makefile</filename>s <quote>do the right thing</quote>
     based on the type of system.</para>
     
     <para>For non-port libraries, it is also our policy to change the shared
       library version number only once between releases.  In addition, it is
       our policy to change the major shared library version number only once
-      between major OS releases.  Ie: X.0 to (X+1).0.  When you make a
+      between major OS releases (i.e. from 3.0 to 4.0).  When you make a
       change to a system library that requires the version number to be
       bumped, check the <filename>Makefile</filename>'s commit logs. It is the
       responsibility of the committer to ensure that the first such change