Tweak the Tier policy and wording slightly to match current reality.

Also, move ia64 to Tier 4 status starting in FreeBSD 11. Keep it in
the Tier 2 status category until FreeBSD 10 ages out of support.

Consistently use Toolchain maintainers (plural) and adjust surrounding
verbs, etc to match.

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
+	list must exist and should be relatively recent.  It should be
-	old.  It should be integrated into the &os;
+	integrated into the &os; documentation.</para>
-	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
+	use. Initial support for Tier 3 platforms should be worked on in
-	source tree.  Support for Tier 3 systems may be worked on in
+	external SCM repositories.
-	the &os; Perforce Repository, providing source control and
+	The transition to &os;'s subversion should take place after
-	easier change integration from the main &os; tree.
+	the platform boots multi-user on hardware; sharing via
-	Platforms that transition to Tier 3 status may be removed from
+	subversion is needed for wider exposure; and multiple
-	the tree if they are no longer actively supported by the
+	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
+      <para>Current Tier 3 platforms are &arch.mips;.</para>
-	&s390;.</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>