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,16 @@
- 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
- ports freeze.
-
- For more information on the background and
- policies surrounding a ports freeze, see the
- Portmgr
- Quality Assurance page.
-
-
-
-
-
- What is a ports slush or
- feature freeze?
-
-
-
- During a release cycle the ports tree may be in a
- slush 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
- sweeping changes are prohibited unless
- specifically permitted by portmgr. Complete details
- about what qualifies as a sweeping change can be found
- on the Portmgr
- Implementation page.
-
- 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.
-
-
-
-
-
- How long is a ports freeze or slush?
-
-
-
- A freeze only lasts long enough to tag the tree.
- A slush usually lasts a week or two, but may last
- longer.
-
-
-
-
-
- What does it mean to me?
-
-
-
- During a ports freeze, you are not allowed to
- commit anything to the tree without explicit approval
- from the Ports Management Team. Explicit
- approval here means that you send a patch to
- the Ports Management Team for review and get a reply
- saying, Go ahead and commit it.
-
- Not everything is allowed to be committed during
- a freeze. Please see the
- Portmgr
- Quality Assurance page for more
- information.
-
- Note that you do not have implicit permission to fix
- a port during the freeze just because it is
- broken.
-
- 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
- Feature Safe: yes) must be added to the
- commit message.
-
-
-
-
-
- How do I know when the ports slush starts?
-
-
-
- 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.
-
- When the slush starts, there will be another
- announcement to the &a.ports; and &a.committers;, of
- course.
-
-
-
-
-
- How do I know when the freeze or slush ends?
-
-
-
- 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.
+ A ports freeze 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
+ .
@@ -4591,9 +4480,14 @@
- The packages are built weekly. If a port fails,
- the maintainer will be emailed from
+ The packages are built multiple times each week. If
+ a port fails, the maintainer will receive an email from
pkg-fallout@FreeBSD.org.
+
+ Reports for all the package builds (official,
+ experimental, and non-regression) are aggregated at
+ pkg-status.FreeBSD.org.