Header And Logo

• Home

• About
  • Introduction
  • Features
  • Advocacy
  • Marketing
  • Privacy Policy

• Get FreeBSD
  • Release Information
  • Release Engineering

• Documentation
  • FAQ
  • Handbook
  • Porter's Handbook
  • Developer's Handbook
  • Manual Pages

• Community
  • Mailing Lists
  • Forums
  • User Groups
  • Events

• Developers
  • Project Ideas
  • SVN Repository
  • Perforce Repository

• Support
  • Vendors
  • Security Information
  • Bug Reports
  • Submit Bug-report

• Foundation
  • Monetary Donations
  • Hardware Donations

Charter for the Release Engineering Team

The Release Engineering Team has the following responsibilities :

• Setting and publishing the release schedule for Official Project releases of FreeBSD.

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

• 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 RELENG_* code freeze pending a -STABLE release.

• Creation and maintenance of RELENG_* branches of the src/ tree. This includes final authority over what commits are made (and remain in) the -STABLE branch prior to the branching of a release branch.

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

• Testing and integrating required packages from the ports collection onto the official project release media. Portmgr@ is responsible for managing the ports/ 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.

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

• 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 (RELENG_X_Y) 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.

• Sending out messages to announce@FreeBSD.org on behalf of the project to announce new releases of FreeBSD.