Differential D28842 Diff 84421 website/content/en/releng/charter.adoc

Changeset View

Standalone View

website/content/en/releng/charter.adoc

	---			---
	title: "Charter for the Release Engineering Team"			title: "Charter for the Release Engineering Team"
	sidenav: developers			sidenav: developers
	---			---

	= Charter for the Release Engineering Team			= Charter for the Release Engineering Team

	The Release Engineering Team has the following responsibilities:			The Release Engineering Team has the following responsibilities:

	* Setting and publishing the release schedule for Official Project releases of FreeBSD.			* 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.			* 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.			* 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.			* 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".			* 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.			* 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 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 transferred 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.			* 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 transferred 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.			* Sending out messages to announce@FreeBSD.org on behalf of the project to announce new releases of FreeBSD.