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

Add a section on procedures and correct some spelling.

Browse source
This commit is contained in:
Scott Long 2004-08-19 18:49:13 +00:00
parent ba0a434481
commit 6ec947cc6c
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=22013
1 changed files with 29 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

33
en/releases/5.3R/policy.sgml
View file

@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY email 'freebsd-qa'>
<!ENTITY date "$FreeBSD$">
<!ENTITY date "$FreeBSD: www/en/releases/5.3R/policy.sgml,v 1.1 2004/08/19 06:53:01 scottl Exp $">
<!ENTITY local.rel "5.3">
<!ENTITY local.rel.tag "5_3">
<!ENTITY title "FreeBSD &local.rel; Code Freeze Policy">
@ -26,7 +26,32 @@
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>
to all branches in sequence as appropriate.</p>
<h1>Procedures</h1>
<p>When a branch is frozen by the release engineering team, all commits to it
must be approved by the team. This applies also to release engineering team
members as well as the rest of the developer community. In other words,
approval is mandatory. This largely applies to the src/ tree, as ports/,
doc/ and www/ tree management is handled separately by the ports and docs
teams as appropriate.<p>
<p>To apply for a commit approval, a message must be sent to re@FreeBSD.org
with the description of exactly what files need to change and why. Including
a diff is encouraged, as is sending a copy of the commit message from the
parent branch if appropriate. A response should usually be expected within
24 hours for less. Once approval is granted, the commit should be done as
soon as possible. Approved commits may be canceled or overridden by the
release engineering team if needed.</p>
<p>Blanket approvals are a special case that can be requested and granted in
certain circumstances. With a blanket approval, the release engineering
team is granting an individual the permission to do commits without
specific approval in a well defined and controlled area of the tree. They
are typically granted to those who are working on tier-2 and tier-3
platforms or on features that are not fully integrated into the tree.
Blanket approvals are completely at the discretion of the release engineering
team and may be revoked or suspended as needed.</p>
<h1>Policy</h1>
@ -57,13 +82,13 @@
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
or cover significant 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
significantly change or improve existing features and behaviors, 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