113 lines · plain
1.. _maintainerentryprofile:2 3Maintainer Entry Profile4========================5 6The Maintainer Entry Profile supplements the top-level process documents7(submitting-patches, submitting drivers...) with8subsystem/device-driver-local customs as well as details about the patch9submission life-cycle. A contributor uses this document to level set10their expectations and avoid common mistakes; maintainers may use these11profiles to look across subsystems for opportunities to converge on12common practices.13 14 15Overview16--------17Provide an introduction to how the subsystem operates. While MAINTAINERS18tells the contributor where to send patches for which files, it does not19convey other subsystem-local infrastructure and mechanisms that aid20development.21 22Example questions to consider:23 24- Are there notifications when patches are applied to the local tree, or25 merged upstream?26- Does the subsystem have a patchwork instance? Are patchwork state27 changes notified?28- Any bots or CI infrastructure that watches the list, or automated29 testing feedback that the subsystem uses to gate acceptance?30- Git branches that are pulled into -next?31- What branch should contributors submit against?32- Links to any other Maintainer Entry Profiles? For example a33 device-driver may point to an entry for its parent subsystem. This makes34 the contributor aware of obligations a maintainer may have for35 other maintainers in the submission chain.36 37 38Submit Checklist Addendum39-------------------------40List mandatory and advisory criteria, beyond the common "submit-checklist",41for a patch to be considered healthy enough for maintainer attention.42For example: "pass checkpatch.pl with no errors, or warning. Pass the43unit test detailed at $URI".44 45The Submit Checklist Addendum can also include details about the status46of related hardware specifications. For example, does the subsystem47require published specifications at a certain revision before patches48will be considered.49 50 51Key Cycle Dates52---------------53One of the common misunderstandings of submitters is that patches can be54sent at any time before the merge window closes and can still be55considered for the next -rc1. The reality is that most patches need to56be settled in soaking in linux-next in advance of the merge window57opening. Clarify for the submitter the key dates (in terms of -rc release58week) that patches might be considered for merging and when patches need to59wait for the next -rc. At a minimum:60 61- Last -rc for new feature submissions:62 New feature submissions targeting the next merge window should have63 their first posting for consideration before this point. Patches that64 are submitted after this point should be clear that they are targeting65 the NEXT+1 merge window, or should come with sufficient justification66 why they should be considered on an expedited schedule. A general67 guideline is to set expectation with contributors that new feature68 submissions should appear before -rc5.69 70- Last -rc to merge features: Deadline for merge decisions71 Indicate to contributors the point at which an as yet un-applied patch72 set will need to wait for the NEXT+1 merge window. Of course there is no73 obligation to ever accept any given patchset, but if the review has not74 concluded by this point the expectation is the contributor should wait and75 resubmit for the following merge window.76 77Optional:78 79- First -rc at which the development baseline branch, listed in the80 overview section, should be considered ready for new submissions.81 82 83Review Cadence84--------------85One of the largest sources of contributor angst is how soon to ping86after a patchset has been posted without receiving any feedback. In87addition to specifying how long to wait before a resubmission this88section can also indicate a preferred style of update like, resend the89full series, or privately send a reminder email. This section might also90list how review works for this code area and methods to get feedback91that are not directly from the maintainer.92 93Existing profiles94-----------------95 96For now, existing maintainer profiles are listed here; we will likely want97to do something different in the near future.98 99.. toctree::100 :maxdepth: 1101 102 ../doc-guide/maintainer-profile103 ../nvdimm/maintainer-entry-profile104 ../arch/riscv/patch-acceptance105 ../process/maintainer-soc106 ../process/maintainer-soc-clean-dts107 ../driver-api/media/maintainer-entry-profile108 ../process/maintainer-netdev109 ../driver-api/vfio-pci-device-specific-driver-acceptance110 ../nvme/feature-and-quirk-policy111 ../filesystems/xfs/xfs-maintainer-entry-profile112 ../mm/damon/maintainer-profile113