os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Document the policy for getting changes into the release during code

Browse source 
freeze.
This commit is contained in:
Scott Long 2004-08-19 06:53:01 +00:00
parent 26028fed90
commit fc6c369e12
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=22000
2 changed files with 91 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
en/releases/5.3R/Makefile
View file

@ -1,4 +1,4 @@
# $FreeBSD: www/en/releases/5.3R/Makefile,v 1.1 2003/11/07 07:31:43 rwatson Exp $
# $FreeBSD: www/en/releases/5.3R/Makefile,v 1.2 2004/08/05 19:57:06 scottl Exp $
.if exists(../Makefile.conf)
.include "../Makefile.conf"
@ -7,7 +7,7 @@
.include "../Makefile.inc"
.endif
DOCS= todo.sgml schedule.sgml
DOCS= todo.sgml schedule.sgml policy.sgml
DATA= docbook.css

89
en/releases/5.3R/policy.sgml Normal file
View file

@ -0,0 +1,89 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY email 'freebsd-qa'>
<!ENTITY date "$FreeBSD$">
<!ENTITY local.rel "5.3">
<!ENTITY local.rel.tag "5_3">
<!ENTITY title "FreeBSD &local.rel; Code Freeze Policy">
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
]>
<html>
&header;
<h1>Introduction</h1>
<p>The following is the general policy for submitting and granting approvals
for committing during the code freeze for FreeBSD &local.rel;. Flexibility
will be granted when deemed appropriate by the Release Engineering Team.
The ultimate purpose of this policy, however, is to minimize risks to the
release process and help encourage good release engineering practices.</p>
<p>This policy applies to the BETA1 - BETA4, RC1 - RC2, and RELEASE release
engineering cycles for the RELENG_5 and RELENG_5_3 branches. During the
BETA cycle, the RELENG_5 branch will be frozen and under strict control
of the Release Engineering team. The HEAD branch will be used to validate
changes that are intended for this branch. Once the RELENG_5_3 branch is
created, the RELENG_5 branch will become unfrozen and will be the
validation ground for RELENG_5_3 changes. Changes should be committed
to all branchs in sequence as appropriate.</p>
<h1>Policy</h1>
<h2>Build fixes</h2>
<p>These are defined as changes that fix source files,
makefiles, or other build components so that the system can be compiled.
This does not include bug fixes to tools or compilers except in rare
circumstances. Build fixes must be committed to the parent branch
first, if applicable, and be tested in all default build configurations.
For kernel sources, this means testing on both GENERIC and LINT kernels.
For userland sources, this means completing and installing the build of
the 'world' target. For both userland and kernel sources, compiling on
both 32-bit and 64-bit platforms is mandatory for machine-independent
code. There is no minimum wait period for these fixes once testing is
complete.</p>
<h2>Bug fixes</h2>
<p>These are defined as changes that fix incorrect behavior in
an existing piece of code or subsystem in the src/ tree. All bugs must
have a PR number, a review by a senior member of the project, and be
vetted through the parent branch for at least 3 full days. We are often
pressured to skirt the rules and put high-priority fixes in early, but we
must resist that and rely on other tools like Perforce and diff/patch toi
get early testing before committing to the tree.</p>
<h2>Documentation fixes</h2>
<p>These are defined as changes to existing documentation in manual pages,
release notes, and doc articles and books. This does <b>not</b> generally
include comments in source files. Documentation fixes must have a PR
number and are encouraged to have a review. Changes that are widespread
or cover signficant technical information should be reviewed without
exception. All changes must be vetted through that parent branch for 2
days.</p>
<h2>Feature additions and modifications</h2>
<p>These are defined as changes that add new features to the system or
signficantly change or improve exsting features and behaviours, but are
not strictly bug fixes. These will only be considered for inclusion if
prior notice is given to the re@ and arch@ mail aliases and the work is
publically available in either patch form or in the FreeBSD Perforce
repository. We reserve the right to reject feature requests based on risk
to stability and risk to the published release schedule. Those that are
allowed need at least 7 days in the parent branch and a thorough review by
at least two parties. Mitigation of risk is highly important here, so
developers are highly encouraged to make their work be modular and able to
be removed or turned off to restore previous behavior. Feature additions
will not be allowed after BETA4. </p>
<h2>Performance improvements</h2>
<p>These are defined as changes that are designed to optimize performance in
a measurable way. Any proposal here must be accompanied by documented
performance and regression testing on all affected arches. On arches with
a clear runtime distinction between UP and SMP, the testing must include
both. Thorough review by two or more senior people is also a firm
requirement. Performance improvements will not be allowed after BETA3.</p>
&footer;
</body>
</html>