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.
+ +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.
+ +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.
+ +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.
+ +These are defined as changes to existing documentation in manual pages, + 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 + exception. All changes must be vetted through that parent branch for 2 + days.
+ +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.
+ +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.
+ +&footer; + + +