<para>How long is a ports freeze?</para>

	    <para>What is a <quote>ports slush</quote> or

	      <quote>feature freeze</quote>?</para>

	    <para>During the ports freeze, you are not allowed to

	    <para>

	      commit anything to the tree without explicit approval

	      During a release cycle the ports tree may be in a  

	      from the Ports Management Team.  <quote>Explicit

	      <quote>slush</quote> state instead of in a hard freeze.

	      approval</quote> here means that you send a patch to

	      The goal during a slush is to reach a stable ports tree

	      the Ports Management Team for review and get a reply

	      to avoid rebuilding large sets of packages for the

	      saying, <quote>Go ahead and commit it.</quote> 

	      release and to tag the tree. During this time

	      <quote>sweeping changes</quote> are prohibited unless

	      specifically permitted by portmgr. Complete details

	      about what consitutes a sweeping change can be found

	      on the <ulink 

	      url="&url.base/portmgr/implementation.html">Portmgr

	      Implementation page</ulink>.

	    <para>

	    <para>Not everything is allowed to be committed during

	      The benefit of using a slush as opposed to a

	      a freeze.  Please see the <ulink

	      complete freeze is that allows maintainers to continue 

		url="&url.base/portmgr/qa.html">Portmgr Quality

	      adding new ports, making routine version updates and 

		Assurance page</ulink> for more information.

	      bug fixes to most existing ports, and otherwise

	    </para>

	      improving the tree without destabilizing things with

	      sweeping changes that have effects far beyond the

	    <para>Note that you do not have implicit permission to fix

	      ports that are changed. For example, updating the

	      a port during the freeze just because it is

	      shared library version on a port that many other

	      broken.</para>

	      ports depend on.

	  </answer>

	</qandaentry>

	<qandaentry>

	  <question>

	    <para>How do I know when the ports freeze 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 freeze 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 freeze starts, there will be another

	      announcement to the &a.ports; and &a.committers;, of course.</para>

	  </answer>

	</qandaentry>

	<qandaentry>

	  <question>

	    <para>How do I know when the ports freeze 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.  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.</para>

	    <para>What is the procedure for creating a new category?</para>

	    <para>How long is a ports freeze or slush?</para>

	    <para>Please see

	    <para>A freeze only lasts long enough to 

	      <ulink url="&url.books.porters-handbook;/makefile-categories.html#PROPOSING-CATEGORIES">

	      tag the tree. A slush usually lasts a week or two,

	      Proposing a New Category</ulink> in the Porter's Handbook.

		but may last longer.</para>

	      Once that procedure has been followed and the PR has been

	    </answer>

	      assigned to &a.portmgr;, it is their decision whether or

	  </qandaentry>

	      not to approve it.  If they do, it is their responsibility

	      to do the following:</para>

	  <qandaentry>

	    <question>

	    <procedure>

	      <para>What does it mean to me?</para>

	      <step>

	    </question>

		<para>Perform any needed repocopies.  (This only applies

		  to physical categories.)</para>

	    <answer>

	      </step>

	      <para>During a ports freeze, you are not allowed to

		commit anything to the tree without explicit approval

	      <step>

		from the Ports Management Team.  <quote>Explicit

		<para>Update the <makevar>VALID_CATEGORIES</makevar>

		approval</quote> here means that you send a patch to

		  definition in <filename>ports/Mk/bsd.port.mk</filename>.

		the Ports Management Team for review and get a reply

		</para>

		saying, <quote>Go ahead and commit it.</quote> 

	      </step>

	      </para>

	      <step>

	      <para>Not everything is allowed to be committed during

		<para>Assign the PR back to you.</para>

		a freeze.  Please see the <ulink

	      </step>

		  url="&url.base/portmgr/qa.html">Portmgr Quality

	    </procedure>

		  Assurance page</ulink> for more information.

	  </answer>

	      </para>

	</qandaentry>

	      <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 must excersise 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>

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

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

		We have to make sure there will not be any last minute

		snafus that result in an immediate re-rolling of the

		release.</para>

	    </answer>

	  </qandaentry>

	</qandadiv>

	<qandadiv>

	  <title>Creating a New Category</title>

	  <qandaentry>

	    <question>

	      <para>What is the procedure for creating a new category?</para>

	    </question>

	    <answer>

	      <para>Please see

		<ulink url="&url.books.porters-handbook;/makefile-categories.html#PROPOSING-CATEGORIES">

		Proposing a New Category</ulink> 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:</para>

	<qandaentry>

	      <procedure>

	  <question>

		<step>

	    <para>What do I need to do to implement a new physical

		  <para>Perform any needed repocopies.  (This only applies

	      category?</para>

		    to physical categories.)</para>

	  </question>

		</step>

	  <answer>

		<step>

	    <para>The procedure is a strict superset of the one to

		  <para>Update the <makevar>VALID_CATEGORIES</makevar>

	      repocopy individual ports (see above).</para>

		    definition in <filename>ports/Mk/bsd.port.mk</filename>.

		  </para>

		</step>

		  <para>Upgrade each copied port's

		  <para>Assign the PR back to you.</para>

		    <filename>Makefile</filename>.  Do not connect the

		</step>

		    new category to the build yet.</para>

	      </procedure>

	    </answer>

	  </qandaentry>

		  <para>To do this, you will need to:</para>

	  <qandaentry>

		    <procedure>

	    <question>

		      <step>

	      <para>What do I need to do to implement a new physical

			<para>Change the port's <makevar>CATEGORIES</makevar>

		category?</para>

			  (this was the point of the exercise, remember?)

	    </question>

	    <answer>

	      <para>The procedure is a strict superset of the one to

		repocopy individual ports (see above).</para>

		<procedure>

		  <step>

		    <para>Upgrade each copied port's

		      <filename>Makefile</filename>.  Do not connect the

		      new category to the build yet.</para>

		    <para>To do this, you will need to:</para>

		      <procedure>

			<step>

			  <para>Change the port's <makevar>CATEGORIES</makevar>

			    (this was the point of the exercise, remember?)