<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "Charter for the Release Engineering Team">
<!ENTITY % navinclude.developers "INCLUDE">
]>

<html>
&header;

<p>The Release Engineering Team has the following responsibilities
:</p>

<ul>
  <li><p>Setting and publishing the release schedule for Official
    Project releases of FreeBSD.</p></li>
    
  <li><p>Documenting and formalizing the RE procedures, so that the
    process can continually be reviewed and improved.  This includes
    more documentation about the ports cluster and package split
    procedures.</p></li>
    
  <li><p>Setting and publishing "Code Freeze" dates, and acting as a
    change-review committee to decide which changes may be made to a
    branch during a code freeze.  This includes freezes for HEAD when
    approaching a .0 release as well as the traditional
    <tt>RELENG_*</tt> code freeze pending a -STABLE release.</p></li>
    
  <li><p>Creation and maintenance of <tt>RELENG_*</tt> branches of the
    <tt>src/</tt> tree.  This include final authority over what
    commits are made (and remain in) the -STABLE branch prior to the
    branching of a release branch.</p></li>

  <li><p>Working with core and/or the FreeBSD Foundation to codify a
    set of guidelines that vendors must meet if they are to be allowed
    to call a product "FreeBSD", or an "Official FreeBSD
    release".</p></li>
      
  <li><p>Testing and integrating required packages from the ports
    collection onto the official project release media.  Portmgr@ is
    responsible for managing the <tt>ports/</tt> code freeze and
    providing a complete package build of the re-distributable ports.
    re@ is then responsible for splitting those packages onto
    different ISOs as required by the release media.  re@ is
    ultimately responsible for ensuring that all of the required
    packages are available on the FreeBSD release media, but portmgr@
    cooperation is essential.</p></li>
      
  <li><p>Coordinating with the FreeBSD Documentation Project, to
    ensure that a consistent set of documentation is provided for the
    release.  This includes the ability to request that large
    disruptive changes not be made to the documentation set in the
    weeks leading up to a release.</p></li>
      
  <li><p>Coordinating with the security officer team to ensure that
    pending FreeBSD releases are not affected by recently disclosed
    vulnerabilities.  Also, approximately 1 week after a release,
    change approval control of release branches (<tt>RELENG_X_Y</tt>)
    is transfered from the release engineers to the security-officer
    team.  The exact transfer date is to be worked out by the two
    parties once it is clear that the release was a success.  A heads
    up message should be sent to developers@ at that time.</p></li>
      
  <li><p>Sending out messages to announce@FreeBSD.org on behalf of
    the project to announce new releases of FreeBSD.</p></li>
</ul>

&footer;
</body>
</html>
