Documentation/doc-guide/maintainer-profile.rst

Source file repositories/reference/linux-study-clean/Documentation/doc-guide/maintainer-profile.rst

File Facts

System
Linux kernel
Corpus path
Documentation/doc-guide/maintainer-profile.rst
Extension
.rst
Size
2348 bytes
Lines
53
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

Documentation subsystem maintainer entry profile
================================================

The documentation "subsystem" is the central coordinating point for the
kernel's documentation and associated infrastructure.  It covers the
hierarchy under Documentation/ (with the exception of
Documentation/devicetree), various utilities under scripts/ and, at least
some of the time, LICENSES/.

It's worth noting, though, that the boundaries of this subsystem are rather
fuzzier than normal.  Many other subsystem maintainers like to keep control
of portions of Documentation/, and many more freely apply changes there
when it is convenient.  Beyond that, much of the kernel's documentation is
found in the source as kerneldoc comments; those are usually (but not
always) maintained by the relevant subsystem maintainer.

The mailing list for documentation is linux-doc@vger.kernel.org.  Patches
should be made against the docs-next tree whenever possible.

Submit checklist addendum
-------------------------

When making documentation changes, you should actually build the
documentation and ensure that no new errors or warnings have been
introduced.  Generating HTML documents and looking at the result will help
to avoid unsightly misunderstandings about how things will be rendered.

All new documentation (including additions to existing documents) should
ideally justify who the intended target audience is somewhere in the
changelog; this way, we ensure that the documentation ends up in the correct
place.  Some possible categories are: kernel developers (experts or
beginners), userspace programmers, end users and/or system administrators,
and distributors.

Key cycle dates
---------------

Patches can be sent anytime, but response will be slower than usual during
the merge window.  The docs tree tends to close late before the merge
window opens, since the risk of regressions from documentation patches is
low.

Review cadence
--------------

I am the sole maintainer for the documentation subsystem, and I am doing
the work on my own time, so the response to patches will occasionally be
slow.  I try to always send out a notification when a patch is merged (or
when I decide that one cannot be).  Do not hesitate to send a ping if you
have not heard back within a week of sending a patch.

Annotation

Implementation Notes