diff options
author | Olof Johansson <olof@lixom.net> | 2019-12-05 13:16:58 -0800 |
---|---|---|
committer | Olof Johansson <olof@lixom.net> | 2019-12-05 13:18:54 -0800 |
commit | 942e6f8a8314e5550e254519dfba4ccd5170421d (patch) | |
tree | 75ec655b440fbc1c454247af38b5596dd8c78de9 /Documentation/maintainer/maintainer-entry-profile.rst | |
parent | 336bab731be76a90291697e51d2aed0ad67d7cb5 (diff) | |
parent | b08baef02b26cf7c2123e4a24a2fa1fb7a593ffb (diff) |
Merge mainline/master into arm/fixes
This brings in the mainline tree right after armsoc contents was merged
this release cycle, so that we can re-run savedefconfig, etc.
Signed-off-by: Olof Johansson <olof@lixom.net>
Diffstat (limited to 'Documentation/maintainer/maintainer-entry-profile.rst')
-rw-r--r-- | Documentation/maintainer/maintainer-entry-profile.rst | 102 |
1 files changed, 102 insertions, 0 deletions
diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst new file mode 100644 index 000000000000..3eaddc8ac56d --- /dev/null +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -0,0 +1,102 @@ +.. _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 gates 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 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 rc release +week) that patches might 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. + +- Last -rc to merge features: Deadline for merge decisions + Indicate to contributors the point at which an as yet un-applied patch + set will need to wait for the NEXT+1 merge window. Of course there is no + obligation to ever except any given patchset, but if the review has not + concluded by this point the expectation the contributor should wait and + resubmit for the following merge window. + +Optional: + +- First -rc at which the development baseline branch, listed in the + overview section, should be considered ready for new submissions. + + +Review Cadence +-------------- +One of the largest sources of contributor angst is how soon to ping +after a patchset has been posted without receiving any feedback. In +addition to specifying how long to wait before a resubmission this +section can also indicate a preferred style of update like, resend the +full series, or privately send a reminder email. This section might also +list how review works for this code area and methods to get feedback +that are not directly from the maintainer. + +Existing profiles +----------------- + +For now, existing maintainer profiles are listed here; we will likely want +to do something different in the near future. + +.. toctree:: + :maxdepth: 1 + + ../nvdimm/maintainer-entry-profile |