Documentation/maintainer/feature-and-driver-maintainers.rst

Source file repositories/reference/linux-study-clean/Documentation/maintainer/feature-and-driver-maintainers.rst

File Facts

System
Linux kernel
Corpus path
Documentation/maintainer/feature-and-driver-maintainers.rst
Extension
.rst
Size
7117 bytes
Lines
167
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

.. SPDX-License-Identifier: GPL-2.0

==============================
Feature and driver maintainers
==============================

The term "maintainer" spans a very wide range of levels of engagement
from people handling patches and pull requests as almost a full time job
to people responsible for a small feature or a driver.

Unlike most of the chapter, this section is meant for the latter (more
populous) group. It provides tips and describes the expectations and
responsibilities of maintainers of a small(ish) section of the code.

Drivers and alike most often do not have their own mailing lists and
git trees but instead send and review patches on the list of a larger
subsystem.

Responsibilities
================

The amount of maintenance work is usually proportional to the size
and popularity of the code base. Small features and drivers should
require relatively small amount of care and feeding. Nonetheless
when the work does arrive (in form of patches which need review,
user bug reports etc.) it has to be acted upon promptly.
Even when a particular driver only sees one patch a month, or a quarter,
a subsystem could well have a hundred such drivers. Subsystem
maintainers cannot afford to wait a long time to hear from reviewers.

The exact expectations on the response time will vary by subsystem.
The patch review SLA the subsystem had set for itself can sometimes
be found in the subsystem documentation. Failing that as a rule of thumb
reviewers should try to respond quicker than what is the usual patch
review delay of the subsystem maintainer. The resulting expectations
may range from two working days for fast-paced subsystems (e.g. networking)
to as long as a few weeks in slower moving parts of the kernel.

Mailing list participation
--------------------------

Linux kernel uses mailing lists as the primary form of communication.
Maintainers must be subscribed and follow the appropriate subsystem-wide
mailing list. Either by subscribing to the whole list or using more
modern, selective setup like
`lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_.

Maintainers must know how to communicate on the list (plain text, no invasive
legal footers, no top posting, etc.)

Reviews
-------

Maintainers must review *all* patches touching exclusively their drivers,
no matter how trivial. If the patch is a tree wide change and modifies
multiple drivers - whether to provide a review is left to the maintainer.

When there are multiple maintainers for a piece of code an ``Acked-by``
or ``Reviewed-by`` tag (or review comments) from a single maintainer is
enough to satisfy this requirement.

If the review process or validation for a particular change will take longer
than the expected review timeline for the subsystem, maintainer should
reply to the submission indicating that the work is being done, and when
to expect full results.

Refactoring and core changes
----------------------------

Occasionally core code needs to be changed to improve the maintainability

Annotation

Implementation Notes