<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY email 'freebsd-qa'>
<!ENTITY date "$FreeBSD$">
<!ENTITY local.rel "5.3">
<!ENTITY local.rel.tag "5_3">
<!ENTITY title "FreeBSD &local.rel; Code Freeze Policy">
<!ENTITY % navinclude.download "INCLUDE">
]>

<html>
&header;

<h1>Introduction</h1>

<p>The following is the general policy for submitting and granting approvals
  for committing during the code freeze for FreeBSD &local.rel;.  Flexibility
  will be granted when deemed appropriate by the Release Engineering Team.
  The ultimate purpose of this policy, however, is to minimize risks to the
  release process and help encourage good release engineering practices.</p>

<p>This policy applies to the BETA1 - BETA4, RC1 - RC2, and RELEASE release
  engineering cycles for the RELENG_5 and RELENG_5_3 branches.  During the
  BETA cycle, the RELENG_5 branch will be frozen and under strict control
  of the Release Engineering team.  The HEAD branch will be used to validate
  changes that are intended for this branch.  Once the RELENG_5_3 branch is
  created, the RELENG_5 branch will become unfrozen  and will be the
  validation ground for RELENG_5_3 changes.  Changes should be committed
  to all branches in sequence as appropriate.</p>

<h1>Procedures</h1>
<p>When a branch is frozen by the release engineering team, all commits to it
  must be approved by the team.  This applies also to release engineering team
  members as well as the rest of the developer community.  In other words,
  approval is mandatory.  This largely applies to the src/ tree, as ports/,
  doc/ and www/ tree management is handled separately by the ports and docs
  teams as appropriate.<p>

<p>To apply for a commit approval, a message must be sent to re@FreeBSD.org
  with the description of exactly what files need to change and why.  Including
  a diff is encouraged, as is sending a copy of the commit message from the
  parent branch if appropriate.  A response should usually be expected within
  24 hours for less.  Once approval is granted, the commit should be done as
  soon as possible.  Approved commits may be canceled or overridden by the
  release engineering team if needed.</p>

<p>Blanket approvals are a special case that can be requested and granted in
  certain circumstances.  With a blanket approval, the release engineering
  team is granting an individual the permission to do commits without
  specific approval in a well defined and controlled area of the tree.  They
  are typically granted to those who are working on tier-2 and tier-3
  platforms or on features that are not fully integrated into the tree.
  Blanket approvals are completely at the discretion of the release engineering
  team and may be revoked or suspended as needed.</p>

<h1>Policy</h1>

<h2>Build fixes</h2>
<p>These are defined as changes that fix source files,
  makefiles, or other build components so that the system can be compiled.
  This does not include bug fixes to tools or compilers except in rare
  circumstances.  Build fixes must be committed to the parent branch
  first, if applicable, and be tested in all default build configurations.
  For kernel sources, this means testing on both GENERIC and LINT kernels.
  For userland sources, this means completing and installing the build of
  the 'world' target.  For both userland and kernel sources, compiling on
  both 32-bit and 64-bit platforms is mandatory for machine-independent
  code.  There is no minimum wait period for these fixes once testing is
  complete.</p>

<h2>Bug fixes</h2>
<p>These are defined as changes that fix incorrect behavior in
  an existing piece of code or subsystem in the src/ tree.  All bugs must
  have a PR number, a review by a senior member of the project, and be
  vetted through the parent branch for at least 3 full days.  We are often
  pressured to skirt the rules and put high-priority fixes in early, but we
  must resist that and rely on other tools like Perforce and diff/patch to
  get early testing before committing to the tree.</p>

<h2>Documentation fixes</h2>
<p>These are defined as changes to existing documentation in manual pages,
  release notes, and doc articles and books.  This does <b>not</b> generally
  include comments in source files.  Documentation fixes are classified into
  trivial and content fixes.
  Trivial fixes are defined as changes which do not need a technical review
  such as fixing a typo, wording, markup error, and so on.
  Content fixes are defined as ones which need a technical review,
  such as changes to the contents of documentation and build infrastructure.</p>

    <h3>Documentation fixes for the src/ tree</h3>
    <p>All changes must be committed to the parent branch first,
      vetted through that branch for 2 days.
      Content fixes must be sent with a PR number when the changes
      are large or involve one of the TODO items (these are periodically
      posted to the freebsd-doc@ mailing list during the release cycle,
      and should also be filed as PRs).  When the changes are self-explaining, send
      them to re@ as an MFC request.
      Changes that are widespread or cover significant technical information
      should be reviewed without exception.</p>

    <h3>Documentation fixes for the doc/ tree</h3>
    <p>Similar policy is applied to the doc/ tree,
      but since doc/ is not branched and is not frozen, trivial fixes
      are allowed to be committed without explicit approval before BETA4.
      Content fixes must be committed with a PR number when the changes
      are large or involve one of the TODO items (these are periodically
      posted to the freebsd-doc@ mailing list during the release cycle,
      and should also be filed as PRs).  When the changes are self-explaining, you can
      commit them into the doc/ tree.  When you are not sure if
      committing your patch without approval is reasonable or not,
      please ask doceng@.  Documentation Engineering Team
      reserves the right to reject and back out your change.
      After BETA4, doc/ slush begins and non-critical
      changes to English documents are discouraged.</p>

    <h3>Translations</h3>
    <p>The above two policies also apply to translations,
      but all changes are considered as trivial changes during
      the period before the doc/ slush is over.</p>

<h2>Feature additions and modifications</h2>
<p>These are defined as changes that add new features to the system or
  significantly change or improve existing features and behaviors, but are
  not strictly bug fixes.  These will only be considered for inclusion if
  prior notice is given to the re@ and arch@ mail aliases and the work is
  publically available in either patch form or in the FreeBSD Perforce
  repository.  We reserve the right to reject feature requests based on risk
  to stability and risk to the published release schedule.  Those that are
  allowed need at least 7 days in the parent branch and a thorough review by
  at least two parties.  Mitigation of risk is highly important here, so
  developers are highly encouraged to make their work be modular and able to
  be removed or turned off to restore previous behavior.  Feature additions
  will not be allowed after BETA4. </p>

<h2>Performance improvements</h2>
<p>These are defined as changes that are designed to optimize performance in
  a measurable way.  Any proposal here must be accompanied by documented
  performance and regression testing on all affected arches.  On arches with
  a clear runtime distinction between UP and SMP, the testing must include
  both.  Thorough review by two or more senior people is also a firm
  requirement.  Performance improvements will not be allowed after BETA3.</p>

&footer;

</body>
</html>
