Modernize the portmgr part of the website (part 1).

- Replace pointyhat.FreeBSD.org by pkg-status.FreeBSD.org
- The ports tree is branched now
- Remove mentions of "repocopies", these were leftovers from the CVS era.
- Update instructions for handling PRs

Parts of the PR were already committed independently by rene
at 2017-01-01 when FreeBSD 9.3, 10.1 and 10.2 reached their EOL.

Apply some igor fixes while here.

PR:		213056
Submitted by:	linimon
Reviewed by:	mat

en_US.ISO8859-1/htdocs/portmgr/policies.xml

@@ -31,7 +31,8 @@
 
 <p>portmgr also runs periodic builds of proposed large changes to the
   Ports Collection on a dedicated area of the automated
-  <a href="http://pointyhat.FreeBSD.org">ports building cluster</a>.
+  <a href="https://pkg-status.freebsd.org">ports building cluster</a>.
+  These are termed experimental builds (often referred to as "exp-runs").
   Examples of changes that should be tested here before committing
   include:</p>
 
@@ -41,13 +42,13 @@
 	X11 servers, GNOME, KDE, autotools, and so forth</p></li>
   <li><p>changes that change the "accepted best practice" for
 	ports Makefiles, such as definitions or usage of common make
-        variables (or <tt>Makevar</tt>s). (e.g. consolidation of
+        variables (or <tt>Makevar</tt>s). (e.g., consolidation of
 	various implementations of USE_*, WITH_*, and so forth)</p></li>
-  <li><p>large repocopies (such as when an existing port category
+  <li><p>large changes to the repository (such as when an existing port category
 	is divided up)</p></li>
 </ul>
 
-<p>Again, since the ports tree is not branched, any large-scale
+<p>Any large-scale
   failures that might be caused by any of the above need to be caught
   first before a large number of user installations are affected.</p>
 
@@ -59,11 +60,10 @@
   commits in certain unusual cases, such as: commits that in their
   opinion destabilize the Ports Collection; violate the
   Principle Of Least Astonishment for FreeBSD's users; or in cases
-  of inter-committer disputes that can not be solved among the
+  of inter-committer disputes that cannot be solved among the
   committers themselves.</p>
 
-<h3>Maintain The Automated <a href="http://pointyhat.FreeBSD.org">
-  Ports Building Cluster</a></h3>
+<h3>Maintain The Automated Ports Building Cluster</h3>
 
 <p>portmgr maintains a set of machines that automatically build
   packages on combinations of FreeBSD source tree versus CPU
@@ -167,7 +167,7 @@
   their status and interest in continuing to work with the ports tree.
   Committers who do not respond to such email, or who respond in the
   negative, have their commit bits reclaimed for safekeeping.
-  Currrently, this period is one year.</p>
+  Currently, this period is one year.</p>
 
 <p>In unusual cases it may become necessary to remove Ports Committers
   for other reasons.  This will only be done after serious deliberation,

en_US.ISO8859-1/htdocs/portmgr/policies_contributors.xml

@@ -21,12 +21,12 @@ responses to issues brought to their attention via email.</p>
 
 <p>The time limit for a maintainer to respond to a PR is two weeks.
   After that period, if it is a minor change, any ports committer can
-  commit the change.  If it is a major change (e.g. would require a
+  commit the change.  If it is a major change (e.g., would require a
   regression run), please contact portmgr first.</p>
 
 <p>We have an add-on to the Problem Reports database known as the auto-assigner,
   which attempts to automatically notify maintainers of PRs; however,
-  it depends on the Synopsis containing category/portname.  In general,
+  it depends on the Summary containing category/portname.  In general,
   various people attempt to catch and fix cases where it does not work,
   but you should not assume so.  Therefore, please
   check to see whether or not the maintainer knows about the PR before
@@ -43,8 +43,7 @@ responses to issues brought to their attention via email.</p>
 
 <p>This period may be shortened by portmgr if the email address returns
   with a hard bounce.  In this case, it is probably desirable to reset
-  all the maintainer's ports and change any PRs set to 'feedback' back
-  to 'open'.</p>
+  all the maintainer's ports and check the status of any PRs.</p>
 
 <a name="commit_privileges"></a>
 <h3>Commit Privileges</h3>

en_US.ISO8859-1/htdocs/portmgr/policies_eol.xml

@@ -14,14 +14,15 @@
     <body class="navinclude.about">
 
 <p>Support of FreeBSD releases by ports and the ports infrastructure
-  matches the <a href="&base;/security/#sup">policies
+  currently matches the <a href="&base;/security/#sup">policies
   set out by the FreeBSD Security Officer</a>.  Once a major branch X
   reaches its EOL date, the "last known good" ports tree will be tagged
   with the <tt>RELEASE_X_EOL</tt> tag as a convenience to those
   remaining users who intend to self-support their installations.
   This tag is not supported in any way and security fixes will not be
   applied.  Usage is therefore highly discouraged and should only be
-  used as a last resort.</p>
+  used if there is no other option; consumers are expected to provide
+  their own support.</p>
 
 <p>For all supported major src branches, all ports will be included in
   an automated quality assurance procedure which will build, install,
@@ -29,7 +30,7 @@
   href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/archs.html#AEN1259">
   Tier 1 platforms</a>.  Maintainers and committers are notified of
   failures detected during testing.  Ports that are known not to build
-  or run on a given supported branch or platform will be marked as
+  or run on a given supported branch and/or platform will be marked as
   such.</p>
 
 <p>Prebuilt binary packages will also be provided for all major branches
@@ -128,7 +129,7 @@
   </tr>
 </table>
 
-<p>Older releases are not maintained, ports and packages may not be able
+<p>Older releases are not maintained; ports and packages may not be able
   to install or run.  Users are strongly encouraged to upgrade to one of
   the supported releases mentioned above.</p>