Content updates: replace FreeBSD with &os; where appropriate, rewrite a

stilted paragraph on SSH.

1 files changed, 68 insertions, 69 deletions

diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml
index ac19299b88..10b36962b0 100644
--- a/en_US.ISO8859-1/articles/committers-guide/article.xml
+++ b/en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -26,7 +26,7 @@
       <year>2011</year>
       <year>2012</year>
       <year>2013</year>
-      <holder>The FreeBSD Documentation Project</holder>
+      <holder>The &os; Documentation Project</holder>
     </copyright>
 
     <legalnotice id="trademarks" role="trademarks">
@@ -43,12 +43,12 @@
     <releaseinfo>$FreeBSD$</releaseinfo>
 
     <abstract>
-      <para>This document provides information for the FreeBSD
+      <para>This document provides information for the &os;
 	committer community.  All new committers should read this
 	document before they start, and existing committers are
 	strongly encouraged to review it from time to time.</para>
 
-      <para>Almost all FreeBSD developers have commit rights to one or
+      <para>Almost all &os; developers have commit rights to one or
 	more repositories.  However, a few developers do not, and some
 	of the information here applies to them as well.  (For
 	instance, some people only have rights to work with the
@@ -56,7 +56,7 @@
 	  linkend="non-committers"/> for more information.</para>
 
       <para>This document may also be of interest to members of the
-	FreeBSD community who want to learn more about how the project
+	&os; community who want to learn more about how the project
 	works.</para>
     </abstract>
   </articleinfo>
@@ -149,27 +149,26 @@
       </tgroup>
     </informaltable>
 
-    <para>It is required that you use &man.ssh.1; to connect to the
-      project hosts.  If you do not know anything about &man.ssh.1;,
-      please see <xref linkend="ssh.guide"/>.</para>
+    <para>&man.ssh.1; is required to connect to the projecte hosts.
+      For more information, see <xref linkend="ssh.guide"/>.</para>
 
     <para>Useful links:</para>
 
     <itemizedlist>
       <listitem>
-	<para><ulink url="&url.base;/internal/">FreeBSD
+	<para><ulink url="&url.base;/internal/">&os;
 	    Project Internal Pages</ulink></para>
       </listitem>
 
       <listitem>
 	<para><ulink
-	    url="&url.base;/internal/machines.html">FreeBSD Project
+	    url="&url.base;/internal/machines.html">&os; Project
 	    Hosts</ulink></para>
       </listitem>
 
       <listitem>
 	<para><ulink
-	    url="&url.base;/administration.html">FreeBSD Project
+	    url="&url.base;/administration.html">&os; Project
 	    Administrative Groups</ulink></para>
       </listitem>
     </itemizedlist>
@@ -178,10 +177,10 @@
   <sect1 id="committer.types">
     <title>Commit Bit Types</title>
 
-    <para>The FreeBSD repository has a number of components which,
+    <para>The &os; repository has a number of components which,
       when combined, support the basic operating system source,
       documentation, third party application ports infrastructure, and
-      various maintained utilities.  When FreeBSD commit bits are
+      various maintained utilities.  When &os; commit bits are
       allocated, the areas of the tree where the bit may be used are
       specified.  Generally, the areas associated with a bit reflect
       who authorized the allocation of the commit bit.  Additional
@@ -1389,7 +1388,7 @@ $target - head/$source:$P,$Q,$R</screen>
 	      according to <xref linkend="subversion-primer-merge"/>
 	      this is also where to do the merge.  Note that in this
 	      example all paths are relative to the top of the svn
-	      repository.  for more information on the directory
+	      repository.  For more information on the directory
 	      layout, see
 	      <xref linkend="subversion-primer-base-layout"/>.</para>
 
@@ -2166,7 +2165,7 @@ ControlPersist yes</screen>
 	    working on.  You do not have to write a comprehensive
 	    biography, just write a paragraph or two about who you are
 	    and what you plan to be working on as a developer in
-	    FreeBSD.  (You should also mention who your mentor will
+	    &os;.  (You should also mention who your mentor will
 	    be).  Email this to the &a.developers; and you will be on
 	    your way!</para>
 	</listitem>
@@ -2334,7 +2333,7 @@ ControlPersist yes</screen>
       If they see a different solution to a problem than you, or even
       a different problem, it is not because they are stupid, because
       they have questionable parentage, or because they are trying to
-      destroy your hard work, personal image, or FreeBSD, but simply
+      destroy your hard work, personal image, or &os;, but simply
       because they have a different outlook on the world.  Different
       is good.</para>
 
@@ -2358,7 +2357,7 @@ ControlPersist yes</screen>
   <sect1 id="gnats">
     <title>GNATS</title>
 
-    <para>The FreeBSD Project utilizes
+    <para>The &os; Project utilizes
       <application>GNATS</application> for tracking bugs and change
       requests.  Be sure that if you commit a fix or suggestion found
       in a <application>GNATS</application> PR, you use
@@ -2376,7 +2375,7 @@ ControlPersist yes</screen>
     <itemizedlist>
       <listitem>
 	<para><ulink
-	    url="&url.articles.pr-guidelines;/index.html">FreeBSD
+	    url="&url.articles.pr-guidelines;/index.html">&os;
 	    Problem Report Handling Guidelines</ulink></para>
       </listitem>
 
@@ -2396,7 +2395,7 @@ ControlPersist yes</screen>
     </itemizedlist>
 
     <para>You can run a local copy of GNATS, and then integrate the
-      FreeBSD GNATS tree by creating an
+      &os; GNATS tree by creating an
       <application>rsync</application> mirror.  Then you can run GNATS
       commands locally, allowing you to query the PR database without
       an Internet connection.</para>
@@ -2441,7 +2440,7 @@ ControlPersist yes</screen>
   <sect1 id="people">
     <title>Who's Who</title>
 
-    <para>Besides the repository meisters, there are other FreeBSD
+    <para>Besides the repository meisters, there are other &os;
       project members and teams whom you will probably get to know in
       your role as a committer.  Briefly, and by no means
       all-inclusively, these are:</para>
@@ -2453,7 +2452,7 @@ ControlPersist yes</screen>
 	<listitem>
 	  <para>doceng is the group responsible for the documentation
 	    build infrastructure, approving new documentation
-	    committers, and ensuring that the FreeBSD website and
+	    committers, and ensuring that the &os; website and
 	    documentation on the FTP site is up to date with respect
 	    to the CVS tree.  It is not a conflict resolution body.
 	    The vast majority of documentation related discussion
@@ -2485,7 +2484,7 @@ ControlPersist yes</screen>
 	    commit that could have been done better, Bruce will be
 	    there to tell you.  Be thankful that someone is.  Bruce is
 	    also very knowledgeable on the various standards
-	    applicable to FreeBSD.</para>
+	    applicable to &os;.</para>
 	</listitem>
       </varlistentry>
 
@@ -2515,7 +2514,7 @@ ControlPersist yes</screen>
 
 	<listitem>
 	  <para>Dag-Erling is the
-	    <ulink url="&url.base;/security/">FreeBSD Security
+	    <ulink url="&url.base;/security/">&os; Security
 	      Officer</ulink> and oversees the
 	    &a.security-officer;.</para>
 	</listitem>
@@ -2529,7 +2528,7 @@ ControlPersist yes</screen>
 	    are not sure of some potential change to the networking
 	    subsystem you have in mind, Garrett is someone to talk
 	    to.  Garrett is also very knowledgeable on the various
-	    standards applicable to FreeBSD.</para>
+	    standards applicable to &os;.</para>
 	</listitem>
       </varlistentry>
 
@@ -2556,14 +2555,14 @@ ControlPersist yes</screen>
 	    <quote>community</quote> issues.  Examples are Core
 	    voting, announcements, etc.</para>
 
-	  <para>The &a.developers; is for the exclusive use of FreeBSD
-	    committers.  In order to develop FreeBSD, committers must
+	  <para>The &a.developers; is for the exclusive use of &os;
+	    committers.  In order to develop &os;, committers must
 	    have the ability to openly discuss matters that will be
 	    resolved before they are publicly announced.  Frank
 	    discussions of work in progress are not suitable for open
-	    publication and may harm FreeBSD.</para>
+	    publication and may harm &os;.</para>
 
-	  <para>All FreeBSD committers are reminded to obey the
+	  <para>All &os; committers are reminded to obey the
 	    copyright of the original author(s) of &a.developers;
 	    mail.  Do not publish or forward messages from the
 	    &a.developers; outside the list membership without
@@ -2576,13 +2575,13 @@ ControlPersist yes</screen>
 
 	  <para>This list is <emphasis>not</emphasis> intended as a
 	    place for code reviews or a replacement for the &a.arch;.
-	    In fact using it as such hurts the FreeBSD Project as it
+	    In fact using it as such hurts the &os; Project as it
 	    gives a sense of a closed list where general decisions
-	    affecting all of the FreeBSD using community are made
+	    affecting all of the &os; using community are made
 	    without being <quote>open</quote>. Last, but not least
 	    <emphasis>never, never ever, email the &a.developers; and
-	    CC:/BCC: another FreeBSD list</emphasis>.  Never, ever
-	    email another FreeBSD email list and CC:/BCC: the
+	    CC:/BCC: another &os; list</emphasis>.  Never, ever
+	    email another &os; email list and CC:/BCC: the
 	    &a.developers;.  Doing so can greatly diminish the
 	    benefits of this list.</para>
 	</listitem>
@@ -2713,7 +2712,7 @@ ControlPersist yes</screen>
   </sect1>
 
   <sect1 id="rules">
-    <title>The FreeBSD Committers' Big List of Rules</title>
+    <title>The &os; Committers' Big List of Rules</title>
 
     <orderedlist>
       <listitem>
@@ -2922,7 +2921,7 @@ ControlPersist yes</screen>
 	<listitem>
 	  <para>Respect existing maintainers if listed.</para>
 
-	  <para>Many parts of FreeBSD are not <quote>owned</quote> in
+	  <para>Many parts of &os; are not <quote>owned</quote> in
 	    the sense that any specific individual will jump up and
 	    yell if you commit a change to <quote>their</quote> area,
 	    but it still pays to check first.  One convention we use
@@ -2940,8 +2939,8 @@ ControlPersist yes</screen>
 	    in question and see if someone has been working recently
 	    or predominantly in that area.</para>
 
-	  <para>Other areas of FreeBSD fall under the control of
-	    someone who manages an overall category of FreeBSD
+	  <para>Other areas of &os; fall under the control of
+	    someone who manages an overall category of &os;
 	    evolution, such as internationalization or networking.
 	    See <ulink
 	      url="&url.base;/administration.html">http://www.FreeBSD.org/administration.html</ulink>
@@ -3054,7 +3053,7 @@ ControlPersist yes</screen>
 	    long absence and committing 10 megabytes worth of
 	    accumulated stuff.  People who abuse this on a regular
 	    basis will have their commit privileges suspended until
-	    they get back from the FreeBSD Happy Reeducation Camp we
+	    they get back from the &os; Happy Reeducation Camp we
 	    run in Greenland.</para>
 	</listitem>
 
@@ -3089,9 +3088,9 @@ ControlPersist yes</screen>
 	    running that code.  If you have a change which also may
 	    break another architecture, be sure and test on all
 	    supported architectures.  Please refer to the <ulink
-	    url="http://www.FreeBSD.org/internal/">FreeBSD Internal
+	    url="http://www.FreeBSD.org/internal/">&os; Internal
 	    Page</ulink> for a list of available resources.  As other
-	    architectures are added to the FreeBSD supported platforms
+	    architectures are added to the &os; supported platforms
 	    list, the appropriate shared testing resources will be
 	    made available.</para>
 	</listitem>
@@ -3118,7 +3117,7 @@ ControlPersist yes</screen>
 	    to improve the software in question; you are still more
 	    than welcome to do so.  Ideally, you should submit your
 	    patches to the vendor.  If your changes are
-	    FreeBSD-specific, talk to the maintainer; they may be
+	    &os;-specific, talk to the maintainer; they may be
 	    willing to apply them locally.  But whatever you do, do
 	    <emphasis>not</emphasis> commit there by yourself!</para>
 
@@ -3131,10 +3130,10 @@ ControlPersist yes</screen>
     <sect2>
       <title>Policy on Multiple Architectures</title>
 
-      <para>FreeBSD has added several new architecture ports during
+      <para>&os; has added several new architecture ports during
 	recent release cycles and is truly no longer an &i386; centric
 	operating system.  In an effort to make it easier to keep
-	FreeBSD portable across the platforms we support, core has
+	&os; portable across the platforms we support, core has
 	developed the following mandate:</para>
 
       <blockquote>
@@ -3229,39 +3228,39 @@ ControlPersist yes</screen>
   <sect1 id="archs">
     <title>Support for Multiple Architectures</title>
 
-    <para>FreeBSD is a highly portable operating system intended to
+    <para>&os; is a highly portable operating system intended to
       function on many different types of hardware architectures.
       Maintaining clean separation of Machine Dependent (MD) and
       Machine Independent (MI) code, as well as minimizing MD code, is
       an important part of our strategy to remain agile with regards
       to current hardware trends.  Each new hardware architecture
-      supported by FreeBSD adds substantially to the cost of code
+      supported by &os; adds substantially to the cost of code
       maintenance, toolchain support, and release engineering.  It
       also dramatically increases the cost of effective testing of
       kernel changes.  As such, there is strong motivation to
       differentiate between classes of support for various
       architectures while remaining strong in a few key architectures
-      that are seen as the FreeBSD "target audience".</para>
+      that are seen as the &os; <quote>target audience</quote>.</para>
 
     <sect2>
       <title>Statement of General Intent</title>
 
-      <para>The FreeBSD Project targets "production quality commercial
+      <para>The &os; Project targets "production quality commercial
 	off-the-shelf (COTS) workstation, server, and high-end
 	embedded systems".  By retaining a focus on a narrow set of
-	architectures of interest in these environments, the FreeBSD
+	architectures of interest in these environments, the &os;
 	Project is able to maintain high levels of quality, stability,
 	and performance, as well as minimize the load on various
 	support teams on the project, such as the ports team,
 	documentation team, security officer, and release engineering
 	teams.  Diversity in hardware support broadens the options for
-	FreeBSD consumers by offering new features and usage
+	&os; consumers by offering new features and usage
 	opportunities (such as support for 64-bit CPUs, use in
 	embedded environments, etc.), but these benefits must always
 	be carefully considered in terms of the real-world maintenance
 	cost associated with additional platform support.</para>
 
-      <para>The FreeBSD Project differentiates platform targets into
+      <para>The &os; Project differentiates platform targets into
 	four tiers.  Each tier includes a specification of the
 	requirements for an architecture to be in that tier,
 	as well as specifying the obligations of developers with
@@ -3282,11 +3281,11 @@ ControlPersist yes</screen>
 	requirement).  In general, all Tier 1 platforms must have
 	build and Tinderbox support either in the FreeBSD.org cluster,
 	or be easily available for all developers.  Embedded platforms
-	may substitute an emulator available in the FreeBSD cluster
+	may substitute an emulator available in the &os; cluster
 	for actual hardware.</para>
 
       <para>Tier 1 architectures are expected to be Production Quality
-	with respects to all aspects of the FreeBSD operating system,
+	with respects to all aspects of the &os; operating system,
 	including installation and development environments.</para>
 
       <para>Tier 1 architectures are expected to be completely
@@ -3327,20 +3326,20 @@ ControlPersist yes</screen>
 	maintainer is 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
-	FreeBSD-local changes have not been incorporated upstream.
+	&os;-local changes have not been incorporated upstream.
 	The toolchain maintainers are expected to provide prompt
 	review of any proposed changes and cannot block, through their
 	inaction, changes going into the tree.  New features added to
-	FreeBSD should be feasible to implement on these platforms,
+	&os; should be feasible to implement on these platforms,
 	but an implementation is not required before the feature may
-	be added to the FreeBSD source tree.  New features that may be
+	be added to the &os; source tree.  New features that may be
 	difficult to implement on Tier 2 architectures should provide
 	a means of disabling them on those architectures.  The
 	implementation of a Tier 2 architecture may be committed to
-	the main FreeBSD tree as long as it does not interfere with
+	the main &os; tree as long as it does not interfere with
 	production work on Tier 1 platforms, or substantially with
 	other Tier 2 platforms.  Before a Tier 2 platform can be added
-	to the FreeBSD base source tree, the platform must be able to
+	to the &os; base source tree, the platform must be able to
 	boot multi-user on actual hardware.  Generally, there must be
 	at least three active developers working on the
 	platform.</para>
@@ -3361,12 +3360,12 @@ ControlPersist yes</screen>
 	system, some external patches for the architecture for ports
 	must be available.</para>
 
-      <para>Tier 2 architectures can be integrated into the FreeBSD
+      <para>Tier 2 architectures can be integrated into the &os;
 	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 FreeBSD
+	old.  It should be integrated into the &os;
 	documentation.</para>
 
       <para>Current Tier 2 platforms are &arch.arm;, &arch.ia64;,
@@ -3384,11 +3383,11 @@ ControlPersist yes</screen>
 	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 FreeBSD Perforce Repository, providing source control and
-	easier change integration from the main FreeBSD tree.
+	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
-	FreeBSD developer community at the discretion of the release
+	&os; developer community at the discretion of the release
 	engineer.</para>
 
       <para>Tier 3 platforms may have ports support, either integrated
@@ -3397,7 +3396,7 @@ ControlPersist yes</screen>
       <para>Tier 3 platforms must have the basics documented for how
 	to build a kernel and how to boot it on at least one target
 	hardware or emulation environment.  This documentation need
-	not be integrated into the FreeBSD tree.</para>
+	not be integrated into the &os; tree.</para>
 
       <para>Current Tier 3 platforms are &arch.mips; and
 	&s390;.</para>
@@ -3417,7 +3416,7 @@ ControlPersist yes</screen>
       <title>Policy on Changing the Tier of an Architecture</title>
 
       <para>Systems may only be moved from one tier to another by
-	approval of the FreeBSD Core Team, which shall make that
+	approval of the &os; Core Team, which shall make that
 	decision in collaboration with the Security Officer, Release
 	Engineering, and toolchain maintenance teams.</para>
     </sect2>
@@ -3486,7 +3485,7 @@ ControlPersist yes</screen>
 	      contributed to the Project before, add that person's
 	      name to the <ulink
 		url="&url.articles.contributors;/contrib-additional.html">Additional
-		Contributors</ulink> section of the FreeBSD
+		Contributors</ulink> section of the &os;
 	      Contributors List.</para>
 
 	    <para>Close the PR if the port came in as a PR.  To close
@@ -4231,7 +4230,7 @@ bak/packages  packages from last complete &lt;major_version&gt; run on &lt;arch&
     <title>Issues Specific to Developers Who Are Not
       Committers</title>
 
-    <para>A few people who have access to the FreeBSD machines do not
+    <para>A few people who have access to the &os; machines do not
       have commit bits.  For instance, the project is willing to give
       access to the GNATS database to contributors who have shown
       interest and dedication in working on Problem Reports.</para>
@@ -4271,7 +4270,7 @@ bak/packages  packages from last complete &lt;major_version&gt; run on &lt;arch&
       </listitem>
 
       <listitem>
-	<para><link linkend="rules">The FreeBSD Committers' Big List
+	<para><link linkend="rules">The &os; Committers' Big List
 	    of Rules</link></para>
       </listitem>
     </itemizedlist>
@@ -4461,14 +4460,14 @@ bak/packages  packages from last complete &lt;major_version&gt; run on &lt;arch&
 		  <entry><literal>Submitted by:</literal></entry>
 		  <entry>The name and e-mail address of the person
 		    that submitted the fix; for committers, just the
-		    username on the FreeBSD cluster.</entry>
+		    username on the &os; cluster.</entry>
 		</row>
 
 		<row>
 		  <entry><literal>Reviewed by:</literal></entry>
 		  <entry>The name and e-mail address of the person or
 		    people that reviewed the change; for committers,
-		    just the username on the FreeBSD cluster.  If a
+		    just the username on the &os; cluster.  If a
 		    patch was submitted to a mailing list for review,
 		    and the review was favorable, then just include
 		    the list name.</entry>
@@ -4478,7 +4477,7 @@ bak/packages  packages from last complete &lt;major_version&gt; run on &lt;arch&
 		  <entry><literal>Approved by:</literal></entry>
 		  <entry>The name and e-mail address of the person or
 		    people that approved the change; for committers,
-		    just the username on the FreeBSD cluster.  It is
+		    just the username on the &os; cluster.  It is
 		    customary to get prior approval for a commit if it
 		    is to an area of the tree to which you do not
 		    usually commit.  In addition, during the run up to
@@ -4643,7 +4642,7 @@ MFC after:          1 month</programlisting>
 	  <para>The mailing lists are archived under
 	    <filename>/g/mail</filename> which will show up as
 	    <filename>/hub/g/mail</filename> with &man.pwd.1;.  This
-	    location is accessible from any machine on the FreeBSD
+	    location is accessible from any machine on the &os;
 	    cluster.</para>
 	</answer>
       </qandaentry>