Documentation/process/2.Process.rst

Source file repositories/reference/linux-study-clean/Documentation/process/2.Process.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/2.Process.rst
Extension
.rst
Size
24258 bytes
Lines
495
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. _development_process:

How the development process works
=================================

Linux kernel development in the early 1990s was a pretty loose affair,
with relatively small numbers of users and developers involved.  With a
user base in the millions and with some 2,000 developers involved over the
course of one year, the kernel has since had to evolve a number of
processes to keep development happening smoothly.  A solid understanding of
how the process works is required in order to be an effective part of it.

The big picture
---------------

The Linux kernel uses a loosely time-based, rolling release development
model.  A new major kernel release (which we will call, as an example, 9.x)
[1]_ happens every two or three months, which comes with new features,
internal API changes, and more. A typical release can contain about 13,000
changesets with changes to several hundred thousand lines of code. Recent
releases, along with their dates, can be found at `Wikipedia
<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.

.. [1] Strictly speaking, the Linux kernel does not use semantic versioning
       number scheme, but rather the 9.x pair identifies major release
       version as a whole number. For each release, x is incremented,
       but 9 is incremented only if x is deemed large enough (e.g.
       Linux 5.0 is released following Linux 4.20).

A relatively straightforward discipline is followed with regard to the
merging of patches for each release.  At the beginning of each development
cycle, the "merge window" is said to be open.  At that time, code which is
deemed to be sufficiently stable (and which is accepted by the development
community) is merged into the mainline kernel.  The bulk of changes for a
new development cycle (and all of the major changes) will be merged during
this time, at a rate approaching 1,000 changes ("patches," or "changesets")
per day.

(As an aside, it is worth noting that the changes integrated during the
merge window do not come out of thin air; they have been collected, tested,
and staged ahead of time.  How that process works will be described in
detail later on).

The merge window lasts for approximately two weeks.  At the end of this
time, Linus Torvalds will declare that the window is closed and release the
first of the "rc" kernels.  For the kernel which is destined to be 9.x,
for example, the release which happens at the end of the merge window will
be called 9.x-rc1.  The -rc1 release is the signal that the time to
merge new features has passed, and that the time to stabilize the next
kernel has begun.

Over the next six to ten weeks, only patches which fix problems should be
submitted to the mainline.  On occasion a more significant change will be
allowed, but such occasions are rare; developers who try to merge new
features outside of the merge window tend to get an unfriendly reception.
As a general rule, if you miss the merge window for a given feature, the
best thing to do is to wait for the next development cycle.  (An occasional
exception is made for drivers for previously-unsupported hardware; if they
touch no in-tree code, they cannot cause regressions and should be safe to
add at any time).

As fixes make their way into the mainline, the patch rate will slow over
time.  Linus releases new -rc kernels about once a week; a normal series
will get up to somewhere between -rc6 and -rc9 before the kernel is
considered to be sufficiently stable and the final release is made.
At that point the whole process starts over again.

As an example, here is how the 5.4 development cycle went (all dates in
2019):

Annotation

Implementation Notes