svn commit: r46632 - head/en_US.ISO8859-1/articles/committers-guide

Author: mat
Date: Thu Apr 30 19:34:03 2015
New Revision: 46632
URL: https://svnweb.freebsd.org/changeset/doc/46632

Log:
  Add pkg-status to the "How do I know if my port is building correctly"
  question.  While there, axe the ports freeze section.
  
  Differential Revision:	https://reviews.freebsd.org/D2403
  Approved by:	gjb, wblock (mentors)
  Sponsored by:	Absolight

Modified:
  head/en_US.ISO8859-1/articles/committers-guide/article.xml

Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml	Thu Apr 30 17:44:47 2015	(r46631)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml	Thu Apr 30 19:34:03 2015	(r46632)
@@ -4250,127 +4250,16 @@ Relnotes:           yes</programlisting>
 	  </question>
 
 	  <answer>
-	    <para>Before a release, it is necessary to restrict
-	      commits to the ports tree for a short period of time
-	      while the packages and the release itself are being
-	      built.  This is to ensure consistency among the various
-	      parts of the release, and is called the
-	      <quote>ports freeze</quote>.</para>
-
-	    <para>For more information on the background and
-	      policies surrounding a ports freeze, see the
-	      <link xlink:href="&url.base;/portmgr/qa.html">Portmgr
-		Quality Assurance page</link>.</para>
-	  </answer>
-	</qandaentry>
-
-	<qandaentry xml:id="ports-qa-freeze-slush">
-	  <question>
-	    <para>What is a <quote>ports slush</quote> or
-	      <quote>feature freeze</quote>?</para>
-	  </question>
-
-	  <answer>
-	    <para>During a release cycle the ports tree may be in a
-	      <quote>slush</quote> state instead of in a hard freeze.
-	      The goal during a slush is to reach a stable ports tree
-	      to avoid rebuilding large sets of packages for the
-	      release and to tag the tree.  During this time
-	      <quote>sweeping changes</quote> are prohibited unless
-	      specifically permitted by portmgr.  Complete details
-	      about what qualifies as a sweeping change can be found
-	      on the <link
-		xlink:href="&url.base;/portmgr/implementation.html">Portmgr
-		Implementation page</link>.</para>
-
-	    <para>The benefit of a slush as opposed to a complete
-	      freeze is that it allows maintainers to continue adding
-	      new ports, making routine version updates, and bug fixes
-	      to most existing ports, as long as the number of
-	      affected ports is minimal.  For example, updating the
-	      shared library version on a port that many other ports
-	      depend on.</para>
-	  </answer>
-	</qandaentry>
-
-	<qandaentry xml:id="ports-qa-freeze-long">
-	  <question>
-	    <para>How long is a ports freeze or slush?</para>
-	  </question>
-
-	  <answer>
-	    <para>A freeze only lasts long enough to tag the tree.
-	      A slush usually lasts a week or two, but may last
-	      longer.</para>
-	  </answer>
-	</qandaentry>
-
-	<qandaentry xml:id="ports-qa-freeze-and-me">
-	  <question>
-	    <para>What does it mean to me?</para>
-	  </question>
-
-	  <answer>
-	    <para>During a ports freeze, you are not allowed to
-	      commit anything to the tree without explicit approval
-	      from the Ports Management Team.  <quote>Explicit
-	      approval</quote> here means that you send a patch to
-	      the Ports Management Team for review and get a reply
-	      saying, <quote>Go ahead and commit it.</quote></para>
-
-	    <para>Not everything is allowed to be committed during
-	      a freeze.  Please see the
-	      <link xlink:href="&url.base;/portmgr/qa.html">Portmgr
-		Quality Assurance page</link> for more
-	      information.</para>
-
-	    <para>Note that you do not have implicit permission to fix
-	      a port during the freeze just because it is
-	      broken.</para>
-
-	    <para>During a ports slush, you are still allowed to
-	      commit but you must exercise more caution in what you
-	      commit.  Furthermore a special note (typically
-	      <quote>Feature Safe: yes</quote>) must be added to the
-	      commit message.</para>
-	  </answer>
-	</qandaentry>
-
-	<qandaentry xml:id="ports-qa-freeze-starts">
-	  <question>
-	    <para>How do I know when the ports slush starts?</para>
-	  </question>
-
-	  <answer>
-	    <para>The Ports Management Team will send out warning
-	      messages to the &a.ports; and &a.committers;
-	      announcing the start of the impending release, usually
-	      two or three weeks in advance.  The exact starting time
-	      will not be determined until a few days before the
-	      actual release.  This is because the ports slush has to
-	      be synchronized with the release, and it is usually not
-	      known until then when exactly the release will be
-	      rolled.</para>
-
-	    <para>When the slush starts, there will be another
-	      announcement to the &a.ports; and &a.committers;, of
-	      course.</para>
-	  </answer>
-	</qandaentry>
-
-	<qandaentry xml:id="ports-qa-freeze-ends">
-	  <question>
-	    <para>How do I know when the freeze or slush ends?</para>
-	  </question>
-
-	  <answer>
-	    <para>A few hours after the release, the Ports Management
-	      Team will send out a mail to the &a.ports; and
-	      &a.committers; announcing the end of the ports freeze or
-	      slush.  Note that the release being cut does not
-	      automatically indicate the end of the freeze.  We have
-	      to make sure there will be no last minute snafus that
-	      result in an immediate re-rolling of the release.</para>
+	    <para>A <quote>ports freeze</quote> was a restricted state
+	      the ports tree was put in before a release.  It was used
+	      to ensure a higher quality for the packages shipped with
+	      a release.  It usually lasted a couple of weeks.  During
+	      that time, build problems were fixed, and the release
+	      packages were built.  This practice is no longer used,
+	      as the packages for the releases are built from the
+	      current stable, quarterly branch.  For more information
+	      on how to merge commits to the quarterly branch, see
+	      <xref linkend="ports-qa-misc-request-mfh"/>.</para>
 	  </answer>
 	</qandaentry>
       </qandadiv>
@@ -4591,9 +4480,14 @@ Relnotes:           yes</programlisting>
 	  </question>
 
 	  <answer>
-	    <para>The packages are built weekly.  If a port fails,
-	      the maintainer will be emailed from
+	    <para>The packages are built multiple times each week.  If
+	      a port fails, the maintainer will receive an email from
 	      <literal>[email protected]</literal>.</para>
+
+	    <para>Reports for all the package builds (official,
+	      experimental, and non-regression) are aggregated at
+	      <link
+		xlink:href="https://pkg-status.freebsd.org/">pkg-status.FreeBSD.org</link>.</para>
 	  </answer>
 	</qandaentry>
 
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"