From 6ec947cc6c06062921ded6be50f8a0333534ed8d Mon Sep 17 00:00:00 2001 From: Scott Long Date: Thu, 19 Aug 2004 18:49:13 +0000 Subject: [PATCH] Add a section on procedures and correct some spelling. --- en/releases/5.3R/policy.sgml | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/en/releases/5.3R/policy.sgml b/en/releases/5.3R/policy.sgml index d6efd03f63..9e55730d4e 100644 --- a/en/releases/5.3R/policy.sgml +++ b/en/releases/5.3R/policy.sgml @@ -1,7 +1,7 @@ - + @@ -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.

+ to all branches in sequence as appropriate.

+ +

Procedures

+

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.

+ +

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.

+ +

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.

Policy

@@ -57,13 +82,13 @@ release notes, and doc articles and books. This does not 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.

Feature additions and modifications

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