blob: a6df8bc7f3a30bd75f3e2320621b03ef461771c4 (
plain) (
tree)
|
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
The FreeBSD Documentation Project
$FreeBSD$
-->
<sect1 xml:id="releng-terms">
<title>Release Engineering Terminology</title>
<para>This section describes some of the terminology used throughout
the rest of this document.</para>
<sect2 xml:id="releng-terms-code-slush">
<title>The Code Slush</title>
<para>Although the code slush is not a hard freeze on the tree,
the &team.re; requests that bugs in the existing code base take
priority over new features.</para>
<para>The code slush does not enforce commit approvals to the
branch.</para>
</sect2>
<sect2 xml:id="releng-terms-code-freeze">
<title>The Code Freeze</title>
<para>The code freeze marks the point in time where all commits to
the branch require explicit approval from the &team.re;.</para>
<para>The &os; <application>Subversion</application> repository
contains several hooks to perform sanity checks before any
commit is actually committed to the tree. One of these hooks
will evaluate if committing to a particular branch requires
specific approval.</para>
<para>To enforce commit approvals by the &team.re;, the Release
Engineer updates
<filename>base/svnadmin/conf/approvers</filename>, and commits
the change back to the repository. Once this is done, any
change to the branch must include an <quote>Approved by:</quote>
line in the commit message.</para>
<para>The <quote>Approved by:</quote> line must match the second
column in <filename>base/svnadmin/conf/approvers</filename>,
otherwise the commit will be rejected by the repository
hooks.</para>
<note>
<para>During the code freeze, &os; committers are urged to
follow the <link
xlink:href="https://wiki.freebsd.org/Releng/ChangeRequestGuidelines">Change
Request Guidelines</link>.</para>
</note>
</sect2>
<sect2 xml:id="releng-terms-kbi-freeze">
<title>The <acronym>KBI</acronym>/<acronym>KPI</acronym>
Freeze</title>
<para><acronym>KBI</acronym>/<acronym>KPI</acronym> stability
implies that the caller of a function across two different
releases of software that implement the function results in the
same end state. The caller, whether it is a process, thread, or
function, expects the function to operate in a certain way,
otherwise the <acronym>KBI</acronym>/<acronym>KPI</acronym>
stability on the branch is broken.</para>
</sect2>
</sect1>
|
