70 lines
3 KiB
Text
70 lines
3 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD$">
|
|
<!ENTITY title "Charter for the Release Engineering Team">
|
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
|
]>
|
|
|
|
<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>
|