diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml
index 8474d91bc9..6390366d0d 100644
--- a/en_US.ISO8859-1/articles/committers-guide/article.xml
+++ b/en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -3723,7 +3723,7 @@ Relnotes:           yes</programlisting>
       <para>Tier 2 platforms are not supported by the security officer
 	and release engineering teams.  Platform maintainers are
 	responsible for toolchain support in the tree.  The toolchain
-	maintainer is expected to work with the platform maintainers
+	maintainers are expected to work with the platform maintainers
 	to refine these changes.  Major new toolchain components are
 	allowed to break support for Tier 2 architectures if the
 	&os;-local changes have not been incorporated upstream.
@@ -3752,7 +3752,7 @@ Relnotes:           yes</programlisting>
 	diminishes.  Well supported niche architectures may also be
 	Tier 2.</para>
 
-      <para>Tier 2 architectures may have some support for them
+      <para>Tier 2 architectures have basic support for them
 	integrated into the ports infrastructure.  They may have cross
 	compilation support added, at the discretion of portmgr.  Some
 	ports must built natively into packages if the package system
@@ -3764,9 +3764,8 @@ Relnotes:           yes</programlisting>
 	handbook.  The basics for how to get a system running must be
 	documented, although not necessarily for every single board or
 	system a Tier 2 architecture supports.  The supported hardware
-	list must exist and should be no more than a couple of months
-	old.  It should be integrated into the &os;
-	documentation.</para>
+	list must exist and should be relatively recent.  It should be
+	integrated into the &os; documentation.</para>
 
       <para>Current Tier 2 platforms are &arch.arm;, &arch.ia64;,
 	&arch.pc98;, &arch.powerpc;, and &arch.sparc64;.</para>
@@ -3777,16 +3776,18 @@ Relnotes:           yes</programlisting>
 
       <para>Tier 3 platforms are not supported by the security officer
 	and release engineering teams.  At the discretion of the
-	toolchain maintainer, they may be supported in the toolchain.
+	toolchain maintainers, they may be supported in the toolchain.
 	Tier 3 platforms are architectures in the early stages of
 	development, for non-mainstream hardware platforms, or which
 	are considered legacy systems unlikely to see broad future
-	use.  New Tier 3 systems will not be committed to the base
-	source tree.  Support for Tier 3 systems may be worked on in
-	the &os; Perforce Repository, providing source control and
-	easier change integration from the main &os; tree.
-	Platforms that transition to Tier 3 status may be removed from
-	the tree if they are no longer actively supported by the
+	use. Initial support for Tier 3 platforms should be worked on in
+	external SCM repositories.
+	The transition to &os;'s subversion should take place after
+	the platform boots multi-user on hardware; sharing via
+	subversion is needed for wider exposure; and multiple
+	developers are actively working on the platform.
+	Platforms that transition to Tier 3 status may be
+	removed from the tree if they are no longer actively supported by the
 	&os; developer community at the discretion of the release
 	engineer.</para>
 
@@ -3798,8 +3799,7 @@ Relnotes:           yes</programlisting>
 	hardware or emulation environment.  This documentation need
 	not be integrated into the &os; tree.</para>
 
-      <para>Current Tier 3 platforms are &arch.mips; and
-	&s390;.</para>
+      <para>Current Tier 3 platforms are &arch.mips;.</para>
     </sect2>
 
     <sect2>
@@ -3809,7 +3809,8 @@ Relnotes:           yes</programlisting>
 	project.</para>
 
       <para>All systems not otherwise classified into a support tier
-	are Tier 4 systems.</para>
+        are Tier 4 systems. The &arch.ia64; platform is transitioning to
+        Tier 4 status in &os; 11.</para>
     </sect2>
 
     <sect2>