The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: note/para
Context English State
RC3 build starts [*]:
RELEASE build starts:
August 19, 2016
RELEASE announcement:
September 2, 2016
Items marked with "[*]" are "as needed".
The <literal>doc/</literal> tree slush is coordinated by the FreeBSD Documentation Engineering Team.
The Ports quarterly branch used is determined by when the final <literal>RC</literal> build is planned. A new quarterly branch is created on the first day of the quarter, so this metric should be used when taking the release cycle milestones into account. The quarterly branch is created by the FreeBSD Ports Management Team.
The <literal>doc/</literal> tree is tagged by the FreeBSD Documentation Engineering Team.
The final Ports package build is done by the FreeBSD Ports Management Team after the final (or what is expected to be final) <literal>RC</literal> build.
If the release is being created from an existing <literal>stable/</literal> branch, the <acronym>KBI</acronym> freeze date can be excluded, since the <acronym>KBI</acronym> is already considered frozen on established <literal>stable/</literal> branches.
When writing the release cycle schedule, a number of things need to be taken into consideration, in particular milestones where the target date depends on predefined milestones upon which there is a dependency. For example, the Ports Collection release tag originates from the active quarterly branch at the time of the last <literal>RC</literal>. This in part defines which quarterly branch is used, when the release tag can happen, and what revision of the ports tree is used for the final <literal>RELEASE</literal> build.
After general agreement on the schedule, the FreeBSD Release Engineering Team emails the schedule to the FreeBSD Developers.
It is somewhat typical that many developers will inform the FreeBSD Release Engineering Team about various works-in-progress. In some cases, an extension for the in-progress work will be requested, and in other cases, a request for <quote>blanket approval</quote> to a particular subset of the tree will be made.
When such requests are made, it is important to make sure timelines (even if estimated) are discussed. For blanket approvals, the length of time for the blanket approval should be made clear. For example, a FreeBSD developer may request blanket approvals from the start of the code slush until the start of the <literal>RC</literal> builds.
In order to keep track of blanket approvals, the FreeBSD Release Engineering Team uses an internal repository to keep a running log of such requests, which defines the area upon which a blanket approval was granted, the author(s), when the blanket approval expires, and the reason the approval was granted. One example of this is granting blanket approval to <filename class="directory">release/doc/</filename> to all FreeBSD Release Engineering Team members until the final <literal>RC</literal> to update the release notes and other release-related documentation.
The FreeBSD Release Engineering Team also uses this repository to track pending approval requests that are received just prior to starting various builds during the release cycle, which the Release Engineer specifies the cutoff period with an email to the FreeBSD developers.
Depending on the underlying set of code in question, and the overall impact the set of code has on FreeBSD as a whole, such requests may be approved or denied by the FreeBSD Release Engineering Team.
The same applies to work-in-progress extensions. For example, in-progress work for a new device driver that is otherwise isolated from the rest of the tree may be granted an extension. A new scheduler, however, may not be feasible, especially if such dramatic changes do not exist in another branch.
The schedule is also added to the Project website, in the <literal>doc/</literal> repository, in <filename>head/en_US.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/schedule.xml</filename>. This file is continuously updated as the release cycle progresses.
In most cases, the <filename>schedule.xml</filename> can be copied from a prior release and updated accordingly.
In addition to adding <filename>schedule.xml</filename> to the website, <filename>head/share/xml/navibar.ent</filename> and <filename>head/share/xml/release.ent</filename> are also updated to add the link to the schedule to various subpages, as well as enabling the link to the schedule on the Project website index page.
The schedule is also linked from <filename>head/en_US.ISO8859-1/htdocs/releng/index.xml</filename>.
Approximately one month prior to the scheduled <quote>code slush</quote>, the FreeBSD Release Engineering Team sends a reminder email to the FreeBSD Developers.
Once the first builds of the release cycle are available, update the <literal>beta.local.where</literal> entity in <filename>head/en_US.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/schedule.xml</filename>. replacing <literal>IGNORE</literal> with <literal>INCLUDE</literal>.
If two parallel release cycles are happening at once, the <literal>beta2.local.where</literal> entity may be used instead.
Release Engineering Terminology
This section describes some of the terminology used throughout the rest of this document.
The Code Slush
Although the code slush is not a hard freeze on the tree, the FreeBSD Release Engineering Team requests that bugs in the existing code base take priority over new features.
The code slush does not enforce commit approvals to the branch.


No matching activity found.

Browse all component changes

Things to check


The string is used as plural, but not using plural forms


Source information

Source string comment
(itstool) path: note/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/freebsd-releng.pot, string 75