Documentation/maintainer/maintainer-entry-profile.rst

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

File Facts

System
Linux kernel
Corpus path
Documentation/maintainer/maintainer-entry-profile.rst
Extension
.rst
Size
4147 bytes
Lines
100
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

.. _maintainerentryprofile:

Maintainer Entry Profile
========================

The Maintainer Entry Profile supplements the top-level process documents
(submitting-patches, submitting drivers...) with
subsystem/device-driver-local customs as well as details about the patch
submission life-cycle. A contributor uses this document to level set
their expectations and avoid common mistakes; maintainers may use these
profiles to look across subsystems for opportunities to converge on
common practices.


Overview
--------
Provide an introduction to how the subsystem operates. While MAINTAINERS
tells the contributor where to send patches for which files, it does not
convey other subsystem-local infrastructure and mechanisms that aid
development.

Example questions to consider:

- Are there notifications when patches are applied to the local tree, or
  merged upstream?
- Does the subsystem have a patchwork instance? Are patchwork state
  changes notified?
- Any bots or CI infrastructure that watches the list, or automated
  testing feedback that the subsystem uses to gate acceptance?
- Git branches that are pulled into -next?
- What branch should contributors submit against?
- Links to any other Maintainer Entry Profiles? For example a
  device-driver may point to an entry for its parent subsystem. This makes
  the contributor aware of obligations a maintainer may have for
  other maintainers in the submission chain.


Submit Checklist Addendum
-------------------------
List mandatory and advisory criteria, beyond the common "submit-checklist",
for a patch to be considered healthy enough for maintainer attention.
For example: "pass checkpatch.pl with no errors, or warning. Pass the
unit test detailed at $URI".

The Submit Checklist Addendum can also include details about the status
of related hardware specifications. For example, does the subsystem
require published specifications at a certain revision before patches
will be considered.


Key Cycle Dates
---------------
One of the common misunderstandings of submitters is that patches can be
sent at any time before the merge window closes and can still be
considered for the next -rc1. The reality is that most patches need to
be settled in soaking in linux-next in advance of the merge window
opening. Clarify for the submitter the key dates (in terms of -rc release
week) that patches might be considered for merging and when patches need to
wait for the next -rc. At a minimum:

- Last -rc for new feature submissions:

  New feature submissions targeting the next merge window should have
  their first posting for consideration before this point. Patches that
  are submitted after this point should be clear that they are targeting
  the NEXT+1 merge window, or should come with sufficient justification
  why they should be considered on an expedited schedule. A general
  guideline is to set expectation with contributors that new feature
  submissions should appear before -rc5.

Annotation

Implementation Notes