From owner-freebsd-doc@FreeBSD.ORG Wed Mar 9 01:20:08 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35670106566C for ; Wed, 9 Mar 2011 01:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DF1748FC15 for ; Wed, 9 Mar 2011 01:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p291K79K020101 for ; Wed, 9 Mar 2011 01:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p291K7rj020100; Wed, 9 Mar 2011 01:20:07 GMT (envelope-from gnats) Resent-Date: Wed, 9 Mar 2011 01:20:07 GMT Resent-Message-Id: <201103090120.p291K7rj020100@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Eitan Adler Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4066C106564A for ; Wed, 9 Mar 2011 01:15:54 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 2330E8FC16 for ; Wed, 9 Mar 2011 01:15:54 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p291FrFP053486 for ; Wed, 9 Mar 2011 01:15:53 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p291Fr5B053485; Wed, 9 Mar 2011 01:15:53 GMT (envelope-from nobody) Message-Id: <201103090115.p291Fr5B053485@red.freebsd.org> Date: Wed, 9 Mar 2011 01:15:53 GMT From: Eitan Adler To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: docs/155391: [patch] add notes about the doc slush to the committer handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 01:20:08 -0000 >Number: 155391 >Category: docs >Synopsis: [patch] add notes about the doc slush to the committer handbook >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 09 01:20:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Eitan Adler >Release: >Organization: >Environment: >Description: The attached patch was discussed on #bsddoc and #bsdports >How-To-Repeat: >Fix: Patch attached with submission follows: Index: article.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v retrieving revision 1.294 diff -u -r1.294 article.sgml --- article.sgml 8 Mar 2011 09:47:13 -0000 1.294 +++ article.sgml 9 Mar 2011 00:39:53 -0000 @@ -2803,135 +2803,177 @@ - How long is a ports freeze? + What is a ports slush or + feature freeze? - - - Usually a week or two. - - - - - - What does it mean to me? - - - During the 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. + + 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 consitutes a sweeping change can be found + on the Portmgr + Implementation page. - - 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. - - - - - - How do I know when the ports freeze 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 freeze has to - be synchronized with the release, and it is usually not - known until then when exactly the release will be - rolled. - - When the freeze starts, there will be another - announcement to the &a.ports; and &a.committers;, of course. - - - - - - How do I know when the ports freeze 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. Note that the - release being cut does not automatically end the freeze. - We have to make sure there will not be any last minute - snafus that result in an immediate re-rolling of the - release. + + The benefit of using a slush as opposed to a + complete freeze is that allows maintainers to continue + adding new ports, making routine version updates and + bug fixes to most existing ports, and otherwise + improving the tree without destabilizing things with + sweeping changes that have effects far beyond the + ports that are changed. For example, updating the + shared library version on a port that many other + ports depend on. - - - - Creating a New Category - What is the procedure for creating a new category? + How long is a ports freeze or slush? - Please see - - Proposing a New Category in the Porter's Handbook. - Once that procedure has been followed and the PR has been - assigned to &a.portmgr;, it is their decision whether or - not to approve it. If they do, it is their responsibility - to do the following: - - - - Perform any needed repocopies. (This only applies - to physical categories.) - - - - Update the VALID_CATEGORIES - definition in ports/Mk/bsd.port.mk. - - - - - Assign the PR back to you. - - - - + 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 must excersise 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. + We have to make sure there will not be any last minute + snafus that result in an immediate re-rolling of the + release. + + + + + + Creating a New Category + + + + What is the procedure for creating a new category? + + + + Please see + + Proposing a New Category in the Porter's Handbook. + Once that procedure has been followed and the PR has been + assigned to &a.portmgr;, it is their decision whether or + not to approve it. If they do, it is their responsibility + to do the following: - - - What do I need to do to implement a new physical - category? - + + + Perform any needed repocopies. (This only applies + to physical categories.) + - - The procedure is a strict superset of the one to - repocopy individual ports (see above). + + Update the VALID_CATEGORIES + definition in ports/Mk/bsd.port.mk. + + - - Upgrade each copied port's - Makefile. Do not connect the - new category to the build yet. + Assign the PR back to you. + + + + - To do this, you will need to: - - - Change the port's CATEGORIES - (this was the point of the exercise, remember?) + + + What do I need to do to implement a new physical + category? + + + + The procedure is a strict superset of the one to + repocopy individual ports (see above). + + + + Upgrade each copied port's + Makefile. Do not connect the + new category to the build yet. + + To do this, you will need to: + + + Change the port's CATEGORIES + (this was the point of the exercise, remember?) The new category should be listed first. This will help to ensure that the PKGORIGIN >Release-Note: >Audit-Trail: >Unformatted: