Page MenuHomeFreeBSD
Files F175600844

D60597.id189501.diff
No OneTemporary
Actions

D60597.id189501.diff
View Options

Index: documentation/content/en/books/developers-handbook/policies/srcmgr.adoc
===================================================================
--- /dev/null
+++ documentation/content/en/books/developers-handbook/policies/srcmgr.adoc
@@ -0,0 +1,75 @@
+[[srcmgr]]
+== Source Management Team Policies
+
+The Source Management Team (srcmgr) oversees development of the FreeBSD base system (src tree). This section documents policies that guide srcmgr's work.
+
+=== Code Review
+
+Code review is strongly encouraged for non-obvious changes. Developers are expected to seek pre-commit review but it is not absolutely required. Developers have discression to select the best too for the changes using the following guidelines.
+
+Use link:{phabricator-guide}[Phabricator] if any of the following apply:
+
+* You are a FreeBSD committer
+* Your change is large or controversial
+* You are collaborating closely with committers
+
+Use GitHub pull requests if both conditions hold:
+
+* You already have a GitHub account
+* The change is straightforward and mature
+
+=== Compilation Requirements
+
+All code committed to src must compile on all supported configurations. The default configuration must always build successfully.
+
+Developers are expected to monitor Jenkins builds for other configurations and fix failures if notified.
+
+=== Testing Requirements
+
+The specific functionality that is being introduced or modified must be run-verified with the final version of the code. Developers should test adjacent areas for regression. Where possible, developers should include tests relevant to the change to help prevent regressions.
+
+Changes should be regression tested. `kyua(1)` is the preferred testing mechanism where applicable, though test coverage is uneven across the codebase. Testing requirements are left to developer discretion based on the nature of the change.
+
+The `tinderbox(1)` procedure is expected for cross-platform changes, but is discretionary for changes with no cross-platform risk.
+
+=== Main Branch Soak Time
+
+All changes must reside in main for at least three days before being merged to a stable branch, except where exigent circumstances exist. The Release Engineer may authorize exceptions to allow building a release.
+
+If a change is not relevant to main, direct commits to stable branches are permitted.
+
+=== Commit Access Policy
+
+Developers are granted commit access based on demonstrated competence and trusted judgment. The core principle is: "you have gained our trust to do what you are competent at; ask where you are not and know when you need to ask."
+
+Srcmgr recognizes two types of commit bits:
+
+* **Explicit repository bits**: Commit access granted for specific areas where the developer demonstrates expertise and commitment to review
+* **General bits**: Commit access across src with the understanding that developers should seek additional review in areas where they do not have explicit bits
+
+The `MAINTAINERS` and `CODEOWNERS` files in the source tree document developers with strong interest in specific areas and availability for timely review.
+
+Once granted a commit bit, developers may commit to any FreeBSD repository subject to that repository's policies.
+
+=== Commit Bit Disabling and Reactivation
+
+Developers who are inactive for 18 months will have their commit bits disabled. This policy is transitioning to 12 months. Srcmgr will contact developers before invoking this limit.
+
+After a deactivation, developers may apply to srcmgr for reactivation when they have concrete patches ready to commit and plan additional work in the coming months.
+
+=== Commit Bit Revocation
+
+Srcmgr may suspend or revoke a commit bit at their discression. Developers may be suspended temporarily when necessary to protect the integrity of the tree; when a "commit war" continues after a warning to stop; or when there's other situations requiring a timeout. Temporary suspensions generally last two weeks or less. Srcmgr, with core approval, may suspend someone for a longer period in extreme cases.
+
+Srcmgr may revoke commit bits for developers who repeatedly cause problems and for which no other remedy is appropriate. The core team must confirm revocations.
+
+=== Stable Branch Management
+
+* Developers may commit to stable branches subject to stable branch policies
+* New features are discouraged on stable branches
+* Application Binary Interface (ABI) changes are not permitted on stable branches
+* The Release Engineer decides when to create new stable branches and manages their lifecycle
+
+All changes must first go through main, unless they are not relevant to main, in which case a direct commit to the stable branch may be made.
+
+The Release Engineer accepts and authorizes requests to merge commits from main to stable branches.

File Metadata

Mime Type
text/plain
Expires
Mon, Oct 12, 11:20 PM (49 m, 34 s)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
40709783
Default Alt Text
D60597.id189501.diff (4 KB)

Event Timeline