1# Contribution Guidelines for GitHub 2 3## General Contributions to FreeBSD 4 5Please read the guidelines in [Contributing to FreeBSD](https://docs.freebsd.org/en/articles/contributing/) 6for all the ways you can contribute to the project, how the project is organized, 7how to build different parts of the project, etc. The 8[developer's handbook](https://docs.freebsd.org/en/books/developers-handbook/) 9is another useful resource. 10 11FreeBSD accepts source code contributions using one of several methods: 12- A GitHub [pull request](https://github.com/freebsd/freebsd-src/pulls) 13- A code review in [Phabricator](https://reviews.freebsd.org/differential) 14- An attachment on a [Bugzilla ticket](https://bugs.freebsd.org) 15- Direct access to the [Git repository](https://cgit.freebsd.org/src/) 16 17The preferred method depends on a few factors including the size or scope of 18the change. GitHub pull requests are preferred for relatively straightforward 19changes where the contributor already has a GitHub account. 20 21A change should be submitted by only one method. For example, please do not 22open a GitHub pull request and create a Phabricator review for the same change 23(unless explicitly requested to do so by a FreeBSD committer). 24 25## GitHub Pull Requests 26 27The _freebsd-src_ GitHub repository is a **publish-only mirror** of the FreeBSD 28_src_ repository. Pull Requests are accepted for **small, low-risk** changes 29that require minimal review and integration effort. 30 31For complex, controversial, security-related, or discussion-heavy changes, use 32the normal FreeBSD review and development process (described below) instead. 33 34Submit a Pull Request if your change: 35 36* Fixes a real, specific problem. 37* Is small in scope and easy to review. 38* Can be committed with **less than ~10 minutes** of additional work. 39* Passes all GitHub CI jobs. 40* Affects roughly **10 or fewer files** and **fewer than 200 lines of changes**. 41 42### When Not to use a Pull Request 43 44Do NOT submit a Pull Request for: 45 46* Security-related changes. 47* Works in progress. 48* Changes that require design discussion, or are likely to be controversial. 49 (Start a mailing list thread to discuss the change first.) 50* Changes needing specialized or cross-subsystem review. 51* Large refactors or mechanical tree-wide changes. 52* Changes generated by AI tools without substantial human review and validation. 53 54### Preparing your Pull Request 55 56Before submitting, ensure: 57 58#### Code Quality 59 60* The changes follow FreeBSD's style guide. See [Style](#Style). 61* _tools/build/checkstyle9.pl_ is run and: 62 * All errors are fixed, **or** 63 * Exceptions are documented in the PR. 64* No trailing whitespace is introduced. 65* Changes compile and work before submitting. 66* Test results (including Kyua tests) are unchanged, unless intentionally 67 modified. 68* Bug fixes include new test cases, when possible. 69 70#### Commit Structure 71 72* Each logical change is a **separate commit**. 73* Fixup commits are squashed into the commit they correct. 74* Each commit is suitable for direct inclusion in the FreeBSD's repository. 75* Pull Request scope must remain stable during review. If feedback expands 76 scope, create a new Pull Request. 77* Rebase your chages (and update with a forced push) when incorporating review 78 feedback, rather than using a merge commit. 79 80#### Commit Messages 81 82Each commit must: 83 84* Follow the [commit log message guide](https://docs.freebsd.org/en/articles/committers-guide/#commit-log-message). 85* Include one ore more `Signed-off-by:` trailers certifying [Developer Certificate of Origin](https://developercertificate.org/). 86* Include `PR: \<bugnumber\>` if fixing a Bugzilla Problem Report. 87* Include the URL of a related code review, if applicable. 88 (Avoid opening both Phabricator/Differential reviews and GitHub Pull Requests 89 for the same change.) 90 91#### Author Information 92 93* Commits use your name and valid email address. 94* GitHub-generated `users.noreply.github.com` addresses cannot be used. 95* See [Author Name and Email](#author-name-and-email) for details. 96 97### Contributor Responsibilities 98 99* Monitor your Pull Request and respond to review feedback promptly. 100* Pull Requests may be closed if there is no response for **one month**. 101 102### Additional Requirements for FreeBSD Committers 103 104* Committers submitting Pull Requests are for pushing their changes to the tree 105 (including obtaining any required approvals). 106* Pull Requests opened by FreeBSD committers may be closed after one month 107 unless there is a strong reason to keep them open. 108 109### Quality Expectations 110 111Low quality submimssions will be rejected. This includes submissions generated 112by AI tools that lack sufficient validation, testing, or understanding by the 113submitter. 114 115A pull request may be closed if there are too many obvious mistakes, or when a 116time-consuming rework is needed. 117 118Automated accounts or chatbots must not submit pull requests or use pull 119request interactions to train AI or LLM systems. 120 121Finally, if we close a pull request because it's not ready yet, or stalled out, 122please don't give up. You can resubmit them later once you have time to finish 123the work, or to have them reconsidered if you think we've made an error in 124closing it. 125 126### Author Name and Email 127 128Please use a name and email address in the `Signed-off-by` trailer and as the 129author of the git commits, since we cannot accept anonymous contributions. It is 130common, but not required, to use some form of your full name. We realize that 131some contributors are not comfortable doing so or prefer to contribute under a 132pseudonym, preferred name, chosen name or similar moniker that might not match 133relevant government records. We can accept your patch, as long as the name and 134email you use are distinctive, identifying, and not misleading. Please note that 135if your patch is accepted, the name and email address will become a permanent 136and immutable part of the public history of the FreeBSD source tree. 137 138The goal of this policy is to allow us to have sufficient information to contact 139you if questions arise about your contribution. Addresses of the form 140something@users.noreply.github.com do not meet this standard since we cannot use 141it to contact you. We can use `.mailmap` for name or email changes and mistakes, 142but is imperfect. 143 144Core (core@freebsd.org) may request authors of significant changes using an 145obvious pseudonym to document their identity more concretely should there be 146issues in the future. The author may request this documentation be kept 147confidential unless needed for legal issues arising from their contributions. 148 149## Style 150 151Avoid adding trailing newlines and whitespace. These slow down the integration 152process and are a distraction. `git diff` will highlight them in red, as will 153the Files Changed tab in the pull request. 154 155For C programs, see [style(9)](https://man.freebsd.org/cgi/man.cgi?query=style&sektion=9) 156for details. You can use [Clang format](https://clang.llvm.org/docs/ClangFormat.html) 157with the top level .clang-format file if you are unsure. The 158[git clang-format](https://github.com/llvm-mirror/clang/blob/master/tools/clang-format/git-clang-format) 159command can help minimize churn by only formatting the areas nearby the changes. While 160not perfect, using these tools will maximize your chances of not having style 161comments on your pull requests. 162 163For [Lua](https://www.lua.org), see 164[style.lua(9)](https://man.freebsd.org/cgi/man.cgi?query=style.lua&sektion=9) 165for details. Lua is used for the boot loader and a few scripts in the base system. 166 167For Makefiles changes, see 168[style.Makefile(5)](https://man.freebsd.org/cgi/man.cgi?query=style.Makefile&sektion=5) 169for details. FreeBSD's base system uses the in-tree make, not GNU Make, so 170[make(1)](https://man.freebsd.org/cgi/man.cgi?query=make&sektion=1) is another useful 171resource. 172 173For manual page changes, see 174[style.mdoc(5)](https://man.freebsd.org/cgi/man.cgi?query=style.mdoc&sektion=5) 175for details. Changes should pass `mandoc -Tlint` and igor (install the latter with `pkg install igor`). 176Please be sure to observe the one-sentence-per-line rule so manual pages properly render. 177Proposed changes to manual pages should not bump the document date until merged. 178 179For shell scripts, avoid using bash. The system shell (/bin/sh) is preferred. 180Shell scripts in the base system cannot use bash or bash extensions 181not present in FreeBSD's [shell](https://man.freebsd.org/cgi/man.cgi?query=sh&sektion=1). 182 183## Signed-off-by 184 185Other projects mandate Signed-off-by to create a paper trail for contributions they 186receive. The Developer Certificate of Origin is an attestation that the person 187making the contribution can do it under the current license of the file. Other 188projects that have 'delegated' hierarchies also use it when maintainers 189integrate these patches and submit them upstream. 190 191Right now, pull requests on GitHub are an experimental feature. We strongly 192suggest that people add this line. It creates a paper trail for infrequent 193contributors. Also, developers that are landing a pull request will use a 194Signed-off-by line to set the author for the commit. 195 196These lines are easy to add with `git commit -s`. 197 198## Submitting as part of class work 199 200If you are a professor or teacher that wishes to have your students submit fixes 201as part of their class work, please contact imp@FreeBSD.org before the semester 202to ensure we allocate the proper resources to process them quickly. We'll give 203you more details when you contact us and thanks for including FreeBSD in your 204class work. It also helps us keep track. 205 206## FreeBSD's Upstreams 207 208Anything that's in the directory `contrib`, `crypto`, `sys/contrib`, 209`sys/crypto/` or `sys/cddl` likely has an upstream we pull from. Please do a 210`git log --merges` in any subdirectory of these you are submitting patches for 211to find out the last time we merged from upstream. If it is in the last 5 years, 212upstream is "active" and you should submit your patches there and let the last 213few people to commit to this file (especially merge commits) know. If it's been 214more than 5 years, upstream is likely inactive so please submit the patch. We 215can sort out if it should go into FreeBSD or upstream. 216