Date: Thu, 30 Apr 2015 19:34:04 +0000 (UTC) From: Mathieu Arnold <mat@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r46632 - head/en_US.ISO8859-1/articles/committers-guide Message-ID: <201504301934.t3UJY4CT007768@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>pkg-fallout@FreeBSD.org</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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201504301934.t3UJY4CT007768>