Properly break some overflowing lines that textproc/igor was reporting.

No visible content changes.

1 files changed, 117 insertions, 112 deletions

diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml
index 5c668f5a0f..5a561ab8a7 100644
--- a/en_US.ISO8859-1/articles/committers-guide/article.xml
+++ b/en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -156,7 +156,8 @@
 	    <entry><emphasis>Noteworthy <literal>src/</literal> SVN
 		Branches</emphasis></entry>
 	    <entry>
-	      <literal>stable/</literal><replaceable>n</replaceable> (<replaceable>n</replaceable>-STABLE),
+	      <literal>stable/</literal><replaceable>n</replaceable>
+	      (<replaceable>n</replaceable>-STABLE),
 	      <literal>head</literal> (-CURRENT)</entry>
 	  </row>
 	</tbody>
@@ -477,8 +478,8 @@ You need a Passphrase to protect your secret key.</screen>
   <sect1 xml:id="subversion-primer">
     <title>Subversion Primer</title>
 
-    <para>New committers are assumed to already be familiar with the basic
-      operation of Subversion.  If not, start by reading the
+    <para>New committers are assumed to already be familiar with the
+      basic operation of Subversion.  If not, start by reading the
       <link xlink:href="http://svnbook.red-bean.com/">Subversion
 	Book</link>.</para>
 
@@ -958,15 +959,15 @@ You need a Passphrase to protect your secret key.</screen>
 
 	<para>This command creates a copy of
 	  <filename>foo.c</filename> named <filename>bar.c</filename>,
-	  with the new file also under version control and with the full
-	  history of <filename>foo.c</filename>:</para>
+	  with the new file also under version control and with the
+	  full history of <filename>foo.c</filename>:</para>
 
 	<screen>&prompt.user; <userinput>svn copy <replaceable>foo.c</replaceable> <replaceable>bar.c</replaceable></userinput></screen>
 
 	<para>This is usually preferred to copying the file with
 	  <command>cp</command> and adding it to the repository with
-	  <command>svn add</command> because this way the new file does not
-	  inherit the original one's history.</para>
+	  <command>svn add</command> because this way the new file
+	  does not inherit the original one's history.</para>
 
 	<para>To move and rename a file:</para>
 
@@ -1301,8 +1302,8 @@ You need a Passphrase to protect your secret key.</screen>
 	  <screen>&prompt.user; svn merge -c <replaceable>r123456</replaceable> ^/head/ <replaceable>checkout</replaceable>
 &prompt.user; svn commit <replaceable>checkout</replaceable></screen>
 
-	  <para>Note that <replaceable>checkout</replaceable>
-	    must be a complete checkout of the branch to which the merge
+	  <para>Note that <replaceable>checkout</replaceable> must be
+	    a complete checkout of the branch to which the merge
 	    occurs.</para>
 
 	  <para>Merges to <literal>releng/</literal> branches must
@@ -1679,8 +1680,8 @@ U    stable/9/share/man/man4/netmap.4
 	      on any file in the tree.</para>
 
 	    <para>Committing is now possible.  However, it is good
-	      practice to make sure that everything is okay by using the
-	      <command>svn stat</command> and
+	      practice to make sure that everything is okay by using
+	      the <command>svn stat</command> and
 	      <command>svn diff</command> commands.</para>
 	  </sect5>
 
@@ -1907,12 +1908,12 @@ U    stable/9/share/man/man4/netmap.4
 
 	<para>Avoid setting up a <application>svnsync</application>
 	  mirror unless there is a very good reason for it.  Such
-	  reasons might be to support
-	  multiple local read-only client machines, or if the network
-	  bandwidth is limited.  Starting a fresh mirror from empty
-	  would take a very long time.  Expect a minimum of 10 hours
-	  for high speed connectivity.  If international links are
-	  involved, expect this to take four to ten times longer.</para>
+	  reasons might be to support multiple local read-only client
+	  machines, or if the network bandwidth is limited.  Starting
+	  a fresh mirror from empty would take a very long time.
+	  Expect a minimum of 10 hours for high speed connectivity.
+	  If international links are involved, expect this to take
+	  four to ten times longer.</para>
 
 	<para>A far better option is to grab a seed file.  It is large
 	  (~1GB) but will consume less network traffic and take less
@@ -1976,9 +1977,9 @@ U    stable/9/share/man/man4/netmap.4
 	  while and is finally committed back to the original branch.
 	  During development code migration in one direction (from
 	  head to the branch only).  No code is committed back to head
-	  until the end.  After the branch is committed back at the end,
-	  it is dead (although a new branch with the same name can be
-	  created after the dead one is deleted).</para>
+	  until the end.  After the branch is committed back at the
+	  end, it is dead (although a new branch with the same name
+	  can be created after the dead one is deleted).</para>
 
 	<para>As per <link
 	    xlink:href="https://people.FreeBSD.org/~peter/svn_notes.txt">https://people.FreeBSD.org/~peter/svn_notes.txt</link>,
@@ -2227,10 +2228,10 @@ freebsd-mfc-after = 2 weeks</programlisting>
 
 	  <para>Wiki Information - After gaining access to the wiki,
 	    some people add entries to the <link
-	      xlink:href="https://wiki.freebsd.org/HowWeGotHere">How We
-	      Got Here</link>,
-	    <link xlink:href="https://wiki.freebsd.org/IRC/Nicknames">
-	      IRC Nicks</link>, and <link
+	      xlink:href="https://wiki.freebsd.org/HowWeGotHere">How
+	      We Got Here</link>, <link
+	      xlink:href="https://wiki.freebsd.org/IRC/Nicknames">IRC
+	      Nicks</link>, and <link
 	      xlink:href="https://wiki.freebsd.org/Community/Dogs">
 	      Dogs of FreeBSD</link> pages.</para>
 	</step>
@@ -2480,7 +2481,8 @@ freebsd-mfc-after = 2 weeks</programlisting>
 	  <row>
 	    <entry><literal>Differential Revision:</literal></entry>
 	    <entry>The full URL of the Phabricator review.  This line
-	      <emphasis>must be the last line</emphasis>.  For example:
+	      <emphasis>must be the last line</emphasis>.  For
+	      example:
 	      <literal>https://reviews.freebsd.org/D1708</literal>.</entry>
 	  </row>
 	</tbody>
@@ -2718,26 +2720,27 @@ Relnotes:           yes</programlisting>
   <sect1 xml:id="developer.relations">
     <title>Developer Relations</title>
 
-    <para>When working directly on your own code or on code
-      which is already well established as your responsibility, then
-      there is probably little need to check with other committers
-      before jumping in with a commit.  Working on a bug in an area of
-      the system which is clearly orphaned (and there are a few such
-      areas, to our shame), the same applies.  Trying
-      to modify something which is clearly being actively
-      maintained by someone else (and it is only by watching the
+    <para>When working directly on your own code or on code which is
+      already well established as your responsibility, then there is
+      probably little need to check with other committers before
+      jumping in with a commit.  Working on a bug in an area of the
+      system which is clearly orphaned (and there are a few such
+      areas, to our shame), the same applies.  Trying to modify
+      something which is clearly being actively maintained by someone
+      else (and it is only by watching the
       <literal><replaceable>repository</replaceable>-committers</literal>
-      mailing list that a developer can really get a feel for just what is and
-      is not) then consider sending the change to them instead, just
-      as a developer would have before becoming a committer.  For ports,
-      contact the listed <varname>MAINTAINER</varname> in the
+      mailing list that a developer can really get a feel for just
+      what is and is not) then consider sending the change to them
+      instead, just as a developer would have before becoming a
+      committer.  For ports, contact the listed
+      <varname>MAINTAINER</varname> in the
       <filename>Makefile</filename>.  For other parts of the
-      repository, if it is not clear who the active maintainer
-      is, it may help to scan the revision history to see who has
-      committed changes in the past.  An example script that lists
-      each person who has committed to
-      a given file along with the number of commits each person has
-      made can be found at on <systemitem>freefall</systemitem> at
+      repository, if it is not clear who the active maintainer is, it
+      may help to scan the revision history to see who has committed
+      changes in the past.  An example script that lists each person
+      who has committed to a given file along with the number of
+      commits each person has made can be found at on
+      <systemitem>freefall</systemitem> at
       <filename>~eadler/bin/whodid</filename>.  If queries go
       unanswered or the committer otherwise indicates a lack of
       interest in the area affected, go ahead and commit it.</para>
@@ -2748,22 +2751,22 @@ Relnotes:           yes</programlisting>
 	output.</para>
     </note>
 
-    <para>If there is any doubt about a commit for any reason at all, have
-      it reviewed by <literal>-hackers</literal> before committing.
-      Better to have it flamed then and there rather than when it is
-      part of the repository.  If a commit does
-      results in controversy erupting, it may be advisable to
-      consider backing the change out again until the matter is
-      settled.  Remember, with a version control system we can
-      always change it back.</para>
-
-    <para>Do not impugn the intentions of others.
-      If they see a different solution to a problem, or even
-      a different problem, it is probably not because they are stupid, because
-      they have questionable parentage, or because they are trying to
-      destroy hard work, personal image, or &os;, but basically
-      because they have a different outlook on the world.  Different
-      is good.</para>
+    <para>If there is any doubt about a commit for any reason at all,
+      have it reviewed by <literal>-hackers</literal> before
+      committing.  Better to have it flamed then and there rather than
+      when it is part of the repository.  If a commit does results in
+      controversy erupting, it may be advisable to consider backing
+      the change out again until the matter is settled.  Remember,
+      with a version control system we can always change it
+      back.</para>
+
+    <para>Do not impugn the intentions of others.  If they see a
+      different solution to a problem, or even a different problem, it
+      is probably not because they are stupid, because they have
+      questionable parentage, or because they are trying to destroy
+      hard work, personal image, or &os;, but basically because they
+      have a different outlook on the world.  Different is
+      good.</para>
 
     <para>Disagree honestly.  Argue your position from its merits,
       be honest about any shortcomings it may have, and be open to
@@ -2843,19 +2846,19 @@ Relnotes:           yes</programlisting>
       </step>
 
       <step>
-	<para>Open new bug.  Choose
-	  <literal>Services</literal> as the Product, and
-	  <literal>Bug Tracker</literal> as the Component.
-	  In bug description list acounts you wish to be merged.</para>
+	<para>Open new bug.  Choose <literal>Services</literal> as the
+	  Product, and <literal>Bug Tracker</literal> as the
+	  Component.  In bug description list acounts you wish to be
+	  merged.</para>
       </step>
 
       <step>
-	<para>Log in using
-	  <systemitem class="domainname">&os;.org</systemitem> account and
-	  post comment to newly opened bug to confirm ownership.  See
-	  <xref linkend="kerberos-ldap"/> for more details on how to
-	  generate or set a password for your
-	  <systemitem class="domainname">&os;.org</systemitem> account.</para>
+	<para>Log in using <systemitem
+	    class="domainname">&os;.org</systemitem> account and post
+	  comment to newly opened bug to confirm ownership.  See <xref
+	    linkend="kerberos-ldap"/> for more details on how to
+	  generate or set a password for your <systemitem
+	    class="domainname">&os;.org</systemitem> account.</para>
       </step>
 
       <step>
@@ -3346,21 +3349,21 @@ Relnotes:           yes</programlisting>
 	  <para>Discuss any significant change
 	    <emphasis>before</emphasis> committing.</para>
 
-	  <para>The repository is not where changes are
-	    initially submitted for correctness or argued over, that
-	    happens first in the mailing lists or by use of the
-	    Phabricator service.  The commit will only happen once
-	    something resembling consensus has been reached.  This
-	    does not mean that permission is required before
-	    correcting every obvious syntax error or manual page
-	    misspelling, just that it is good to develop a feel
-	    for when a proposed change is not quite such a no-brainer
-	    and requires some feedback first.  People really do not
-	    mind sweeping changes if the result is something clearly
-	    better than what they had before, they just do not like
-	    being <emphasis>surprised</emphasis> by those changes.
-	    The very best way of making sure that things are on the right
-	    track is to have code reviewed by one or more other
+	  <para>The repository is not where changes are initially
+	    submitted for correctness or argued over, that happens
+	    first in the mailing lists or by use of the Phabricator
+	    service.  The commit will only happen once something
+	    resembling consensus has been reached.  This does not mean
+	    that permission is required before correcting every
+	    obvious syntax error or manual page misspelling, just that
+	    it is good to develop a feel for when a proposed change is
+	    not quite such a no-brainer and requires some feedback
+	    first.  People really do not mind sweeping changes if the
+	    result is something clearly better than what they had
+	    before, they just do not like being
+	    <emphasis>surprised</emphasis> by those changes.  The very
+	    best way of making sure that things are on the right track
+	    is to have code reviewed by one or more other
 	    committers.</para>
 
 	  <para>When in doubt, ask for review!</para>
@@ -3828,10 +3831,10 @@ Relnotes:           yes</programlisting>
 	(features which are inherently architecture-specific, such as
 	support for hardware device drivers, may be exempt from this
 	requirement).  In general, all Tier 1 platforms must have
-	build and test automation support either in the FreeBSD.org cluster,
-	or easily available for all developers.  Embedded platforms
-	may substitute an emulator available in the FreeBSD.org cluster
-	for actual hardware.</para>
+	build and test automation support either in the FreeBSD.org
+	cluster, or easily available for all developers.  Embedded
+	platforms may substitute an emulator available in the
+	FreeBSD.org cluster for actual hardware.</para>
 
       <para>Tier 1 architectures are expected to be Production Quality
 	with respects to all aspects of the &os; operating system,
@@ -4296,13 +4299,13 @@ Relnotes:           yes</programlisting>
 		      rare cases it may be necessary to change the
 		      <varname>PORTNAME</varname> instead of adding
 		      <varname>PKGNAMEPREFIX</varname> or
-		      <varname>PKGNAMESUFFIX</varname>, but this
-		      is only done when it is really needed
-		      &mdash; for example, using an existing port as the base
-		      for a very similar program with a different
-		      name, or upgrading a port to a new upstream
-		      version which actually changes the distribution
-		      name, like the transition from
+		      <varname>PKGNAMESUFFIX</varname>, but this is
+		      only done when it is really needed &mdash; for
+		      example, using an existing port as the base for
+		      a very similar program with a different name, or
+		      upgrading a port to a new upstream version which
+		      actually changes the distribution name, like the
+		      transition from
 		      <filename>textproc/libxml</filename> to
 		      <filename>textproc/libxml2</filename>.  In most
 		      cases, adding or changing
@@ -4424,14 +4427,15 @@ Relnotes:           yes</programlisting>
 
 	    <programlisting>MFH:	<replaceable>2014Q1</replaceable></programlisting>
 
-	    <para>It will automatically notify the &a.ports-secteam; and
-	      the &a.portmgr;.  They will then decide if the commit can be
-	      merged and answer with the procedure.</para>
+	    <para>It will automatically notify the &a.ports-secteam;
+	      and the &a.portmgr;.  They will then decide if the
+	      commit can be merged and answer with the
+	      procedure.</para>
 
 	    <para>If the commit has already been made, send an email
-	      to the &a.ports-secteam; and the &a.portmgr; with the revision
-	      number and a small description of why the commit needs
-	      to be merged.</para>
+	      to the &a.ports-secteam; and the &a.portmgr; with the
+	      revision number and a small description of why the
+	      commit needs to be merged.</para>
 	  </answer>
 	</qandaentry>
 
@@ -4442,7 +4446,8 @@ Relnotes:           yes</programlisting>
 	  </question>
 
 	  <answer>
-	    <para>The following blanket approvals are in effect:</para>
+	    <para>The following blanket approvals are in
+	      effect:</para>
 
 	    <important>
 	      <para>These fixes <emphasis>must</emphasis> be
@@ -4459,7 +4464,7 @@ Relnotes:           yes</programlisting>
 		  <listitem>
 		    <para><filename>pkg-descr</filename>:
 		      <literal>WWW:</literal> URL updates (existing
-		      404, moved or incorrect)</para> 
+		      404, moved or incorrect)</para>
 		  </listitem>
 		</itemizedlist>
 	      </listitem>
@@ -4490,12 +4495,13 @@ Relnotes:           yes</programlisting>
 	      </listitem>
 
 	      <listitem>
-		<para>Adding/fixing <varname>CONFLICTS</varname>.</para>
+		<para>Adding/fixing
+		  <varname>CONFLICTS</varname>.</para>
 	      </listitem>
 
 	      <listitem>
-		<para>Web Browsers, browser plugins, and their required
-		  dependencies.</para>
+		<para>Web Browsers, browser plugins, and their
+		  required dependencies.</para>
 	      </listitem>
 	    </itemizedlist>
 
@@ -4599,12 +4605,11 @@ Do you want to commit? (no = start a shell) [y/n]</screen>
 		been merged because they were not security related.
 		Add the different revisions <emphasis>in the order
 		  they were committed</emphasis> on the
-		<command>mfh</command> command line.
-		The new commit log message will contain the combined
-		log messages from all the original commits.  These
-		messages <emphasis>must</emphasis> be edited to show
-		what is actually being done with the new
-		commit.</para>
+		<command>mfh</command> command line.  The new commit
+		log message will contain the combined log messages
+		from all the original commits.  These messages
+		<emphasis>must</emphasis> be edited to show what is
+		actually being done with the new commit.</para>
 
 	      <screen>&prompt.user; <userinput>/usr/ports/Tools/scripts/mfh r407208 r407713 r407722 r408567 r408943 r410728</userinput></screen>
 	    </tip>