1 files changed, 3 insertions, 3 deletions

diff --git a/en_US.ISO8859-1/articles/5-roadmap/article.sgml b/en_US.ISO8859-1/articles/5-roadmap/article.sgml
index 5600d988b5..38379dc52c 100644
--- a/en_US.ISO8859-1/articles/5-roadmap/article.sgml
+++ b/en_US.ISO8859-1/articles/5-roadmap/article.sgml
@@ -56,7 +56,7 @@
       3.<replaceable>X</replaceable> series.  Work on 3-CURRENT trudged along
       seemingly forever, and finally a cry was made to <quote>just ship it</quote> and
       clean up later.  This decision resulted in the 3.0 and 3.1 releases
-      being very unsatisfying for most, and it wasn't until 3.2 that the
+      being very unsatisfying for most, and it was not until 3.2 that the
       series was considered <quote>stable</quote>.  To make matters worse, the &t.releng.3;
       branch was created along with the 3.0 release, and the &t.releng.head; branch was
       allowed to advance immediately towards 4-CURRENT.  This resulted in a
@@ -64,7 +64,7 @@
       &t.releng.3; branch very difficult.  &os; 2.2.8 was left for quite a while
       as the last production-quality version of &os;.</para>
 
-    <para>Our intent is to avoid repeating that scenario with &os; 5.x.
+    <para>Our intent is to avoid repeating that scenario with &os; 5.X.
       Delaying the &t.releng.5; branch until it is stable and production quality
       will ensure that it stays maintainable and provides a compelling reason
       to upgrade from 4.<replaceable>X</replaceable>.  To do this, we must
@@ -428,7 +428,7 @@
 
         <listitem>
           <para>busdma interface and drivers: architectures like PAE/&i386; and
-            sparc64 which don't have a direct mapping between host memory
+            sparc64 which do not have a direct mapping between host memory
             address space and expansion bus address space require the
             elimination for vtophys() and friends.  The busdma interface was
             created to handle exactly this problem, but many drivers do not use