os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add pkg-status to the "How do I know if my port is building correctly"

Browse source 
question.  While there, axe the ports freeze section.

Differential Revision:	https://reviews.freebsd.org/D2403
Approved by:	gjb, wblock (mentors)
Sponsored by:	Absolight
This commit is contained in:
Mathieu Arnold 2015-04-30 19:34:03 +00:00
parent 1e97df5894
commit 48f66a431f
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=46632
1 changed files with 17 additions and 123 deletions
Download patch file Download diff file Expand all files Collapse all files

140
en_US.ISO8859-1/articles/committers-guide/article.xml
View file

@ -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>