Page MenuHomeFreeBSD

D2403.id5092.diff
No OneTemporary

D2403.id5092.diff

Index: en_US.ISO8859-1/articles/committers-guide/article.xml
===================================================================
--- en_US.ISO8859-1/articles/committers-guide/article.xml
+++ en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -4250,127 +4250,17 @@
</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>Historically, to ensure the quality of the packages
+ shipped with a release the ports tree used to be in a
+ restricted state for a short period of time while most
+ builds problems were fixed, and while the packages and
+ the release itself were being built. This was called
+ the <quote>ports freeze</quote>. 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 +4481,13 @@
</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 be emailed from
<literal>pkg-fallout@FreeBSD.org</literal>.</para>
+
+ <para>In addition, 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>

File Metadata

Mime Type
text/plain
Expires
Tue, Apr 7, 7:07 AM (8 h, 37 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
31017803
Default Alt Text
D2403.id5092.diff (6 KB)

Event Timeline