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.