Source string Read only

(itstool) path: note/para
Context English State
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.


No matching activity found.

Browse all component changes

Things to check


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



English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: note/para
No labels currently set.
Source string location
Source string age
9 months ago
Translation file
, string 75