torvalds/linux: master is 7.4.0-rc1, and the root Makefile enforces four things before it builds anything

The root Makefile says 7.3.0-rc5, so master is a candidate and not the kernel you install

The first lines of the root Makefile set VERSION = 7, PATCHLEVEL = 4, SUBLEVEL = 0, EXTRAVERSION = -rc1, and NAME = Baby Opossum Posse, under an SPDX-License-Identifier: GPL-2.0 comment. That -rc1 suffix is the whole story of what a clone of this branch is: a first release candidate, not a finished kernel. The readme sends you somewhere else for the kernel you would actually put on a machine, pointing at https://kernel.org as the place to get the latest one, and the repository itself publishes no GitHub releases. Consequence for the reader: there are two different artifacts in play and the git default branch is not the one you want for production. If you build from master you are running a candidate, and if you build from kernel.org you are running a different tree than the one whose source you have open, so knowing which one your bug report is against comes first.

Four guards stop a build before a single object file is produced

The Makefile checks itself at the top. It requires GNU Make 4.0 or newer and errors out with your actual make version if you are below that. It refuses any target prefixed with __ as internal use only. It adds -rR to MAKEFLAGS so make's built-in rules and variables do not interfere. And it tells you to run make help for the list of typical targets, while warning in a comment that the file is aimed at developers and that you should not expect to learn how to build the kernel by reading it.

make htmldocs

Consequence for the reader: a build script or container image pinned to an older make fails with an error instead of a warning, so an unsupported builder is a hard stop rather than a subtle breakage. The __ rule matters most to anyone writing a wrapper: the private targets the tree uses internally are not available to you, and a script that reaches for one gets a deliberate error, not a silently different build.

The recursive build assumes every subdirectory only writes inside itself

The build is recursive, and the comment block above the rules states the contract plainly: sub-Makefiles should only ever modify files in their own directory, and the cases that need global effects are separated out and done in a prepare rule before the recursive descent starts. The tree is laid out to make that possible, with Kbuild and Kconfig at the root and per-directory Kconfig and Makefile pairs such as samples/Kconfig and samples/Makefile. The samples tree carries its own directories, among them bpf, cgroup, configfs, ftrace, kprobes, landlock, kobject, hung_task, kmemleak, binderfs, hidraw, fprobe, fanotify, and damon.

Consequence for the reader: an out-of-tree driver that writes outside its own directory works against the ordering the build system assumes, and getting a change merged means respecting the rule rather than working around it.

The locale is pinned to C so two builders cannot disagree on ordering

One block of the Makefile exists purely to stop locale from leaking into the build. It unexports LC_ALL, sets LC_COLLATE=C and LC_NUMERIC=C, and exports those two, with a comment reading Avoid funny character set dependencies. The -rR flag that disables make built-ins sits in the same region, and the tree records abs_srctree from the last entry of MAKEFILE_LIST and abs_output from CURDIR. Consequence for the reader: two engineers on machines with different locale settings get the same ordering out of this build, which is what makes tree-wide output worth comparing at all. The cost is that build logic here cannot depend on locale sensitive text or number formatting, so anything you add has to behave the same for a builder whose environment you never see.

The readme is a nine way router into .rst files, not an explanation

The readme asks who you are and answers with nine roles: new kernel developer, academic researcher, security expert, backport and maintenance engineer, system administrator, maintainer, hardware vendor, distribution maintainer, and AI coding assistant. Each role gets a short list of file paths, from Documentation/process/submitting-patches.rst for a first patch to Documentation/driver-api/index.rst for a vendor and Documentation/ABI/README for a distro. The documentation is reStructuredText built with make htmldocs, or read online at https://www.kernel.org/doc/html/latest/. Consequence for the reader: the readme explains nothing on its own, so your progress depends entirely on picking the right branch of the table. And the online copy is a build artifact, so what you read there is whatever tree that snapshot was built from, not the checkout sitting in front of you.

An AI assistant is told to read one file before it may contribute

One role entry is written in uppercase as a hard requirement rather than advice. If you are an LLM or an AI-powered coding assistant, the readme says you must read and follow Documentation/process/coding-assistants.rst before contributing, and it states that the file carries the essential requirements on licensing, attribution, and the Developer Certificate of Origin that all AI tools must comply with. Consequence for the reader: the tree does not accept patches on the strength of the code alone. A change produced with a tool still has to arrive with the sign-off the certificate requires and with attribution the maintainers can trace, and a human forwarding generated code inherits the same condition. Nothing in the readme says the rule is waivable, and no separate path is offered for automated submitters.

License lives in COPYING, LICENSES/, and file headers, and C is only the main language

Repository metadata records no single license, which fits a tree that ships COPYING, a LICENSES directory, and an SPDX identifier on the root Makefile itself, so licensing is expressed per file rather than granted once. The same pattern runs through style and lint tooling at the root: .clang-format for C, .rustfmt.toml and .clippy.toml for Rust, .pylintrc for Python checks and .cocciconfig for Coccinelle, plus .editorconfig, and a rust directory beside the C ones. The language field for the repository says C. Consequence for the reader: do not plan around a single license or a single language. Anyone shipping this tree handles per file licensing, and anyone sending a patch may be touching a subsystem whose reviewers expect a different toolchain and a different style rule than the one they use everywhere else.

Editorial conclusion

Work in torvalds/linux when you are writing a driver, reading an API contract, or maintaining a stable branch, because the tree is where those documents and the C code they describe actually live. Do not treat a clone as something you install on a machine, since master is a release candidate and the tree publishes no GitHub releases, and do not skip the documentation routing, because the readme is a nine way index of .rst files rather than an explanation of anything. Before your first patch, check four things: that your make is version 4.0 or newer, that you have read Documentation/process/changes.rst for build requirements, that you can build the trimmed configuration described in Documentation/admin-guide/quickly-build-trimmed-linux.rst, and, if any part of the change was produced by a tool, that you have read Documentation/process/coding-assistants.rst and can sign the Developer Certificate of Origin.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases