Linux 7.3-rc2 is development code, while 7.2.4 is stable
The torvalds/linux repository is the mainline kernel tree. On September 9, 2026, kernel.org listed 7.3-rc2 as mainline and 7.2.4 as stable. This distinction matters more than the GitHub star count: mainline is where subsystem work meets before a final release, while stable and long-term branches receive fixes intended for deployed systems. Most users should get a kernel from their operating-system vendor instead of installing this tree directly.
The source covers far more than a bootable binary. Its documentation routes readers to memory management, scheduling, networking, filesystems, locking, power management, driver APIs, security modules, tracing, kernel parameters, and the userspace ABI. Hardware vendors and distribution maintainers need that breadth. An application developer looking for ordinary Linux APIs will learn more from libc, system-call, or framework documentation than by wandering through roughly 34,546,004 lines of kernel source.
What happened when we ran it
Our sandbox checked out commit 893e117, then detected a Python project under Documentation/sphinx/. Installing that project took 27 seconds, added 51 packages, and used 98 MB. Its build completed in 7 seconds. These are documentation-tooling results from an unprivileged Debian container with 3 CPUs and 8 GB of RAM. We did not compile a kernel image, modules, or a hardware-specific configuration.
The measured checkout occupied 1,637.9 MB and contained 95,798 files with roughly 34,546,004 source lines. The Python project exposed no test script or target, so the lab skipped tests rather than reporting a pass. Pip-audit found 0 known vulnerabilities among those installed Python packages. Our scan found no CI workflow files, Dockerfile, or tests directory at the repository root; none of those absences means the kernel lacks its own testing systems.
GitHub shows 3 open items because kernel review happens elsewhere
GitHub recorded 247,613 stars, a last push on September 8, 2026, and 3 combined open issues and pull requests. The repository has GitHub Issues disabled and publishes no GitHub Releases, so those two fields are poor health indicators here. Kernel.org published stable 7.2.4 on September 7 and mainline 7.3-rc2 on September 6. Fresh pushes plus those release channels show current work; issue handling belongs to mailing lists, Bugzilla where a subsystem uses it, and maintainer-specific routes.
The reporting guide asks users to search LKML and the relevant subsystem archives, test a recent vanilla kernel, identify the responsible area, and copy its maintainer and list. Regression reports get special routing, and security problems go to a private address. That process asks more of a reporter than opening a GitHub form. It also puts the discussion in front of the people who own the affected driver or subsystem rather than one central triage queue.
Patches go by email and require a human sign-off
The submission guide recommends git send-email, inline plain-text patches, and recipients selected from MAINTAINERS with scripts/get_maintainer.pl. Each logical change should stand on its own, pass checkpatch.pl, and leave intermediate commits usable for bisection. A Signed-off-by line certifies the Developer Certificate of Origin under a known identity. Teams built around a GitHub pull-request queue must adapt their tooling and review habits before their first contribution.
Linux now has explicit rules for AI coding assistants. The human must review generated code, confirm licensing, add the DCO sign-off, and take responsibility. An AI agent must not add Signed-off-by; assisted work uses an Assisted-by tag. The guide also requires a reproducer for a nontrivial bug, a working fix, verification, maintainer selection, and an honest account of anything that could not be run. That is a useful boundary for any automated contribution pipeline.
A 95,798-file checkout still needs hardware-specific judgment
The official trimmed-kernel guide starts from an existing machine configuration and warns that localmodconfig may omit drivers for disconnected devices or unused virtualization features. Secure Boot can block a self-compiled image, distribution packaging differs, and installation touches boot and module paths. Keep a known working kernel and recovery media. Our 7-second helper build offers no evidence that a selected kernel configuration will compile, boot, or drive the target machine.
Build requirements span the C toolchain, GNU make, binutils, flex, bison, Perl, Python, and optional tools tied to selected features. Rust support has its own checks. Configuration decides which filesystems, drivers, security features, debug data, signing paths, and architectures enter the result. This is why a clean source tree cannot be scored like a command-line application: setup ends only after the kernel boots on the intended hardware and the required devices still work.
FreeBSD and seL4 answer different operating-system questions
FreeBSD's source tree combines a BSD kernel with its base userland, which appeals to teams that want one operating-system project boundary. OpenBSD makes a different whole-system trade around its security practices. seL4 is a microkernel with formal verification and a much smaller trusted base. None is a drop-in alternative for software, drivers, containers, and operational tooling already built around Linux 7.x interfaces.
Use torvalds/linux for upstream kernel work, source inspection, driver development, research, or reproducing a mainline bug. For a production machine, begin with the stable or long-term release policy of the distribution that will support it. The 1,637.9 MB checkout and email review process are manageable details for a kernel team; for everyone else, they are signs that the packaged kernel is the product they wanted.