1 .. _maintainerentryprofile: 1 .. _maintainerentryprofile:
2 2
3 Maintainer Entry Profile 3 Maintainer Entry Profile
4 ======================== 4 ========================
5 5
6 The Maintainer Entry Profile supplements the t 6 The Maintainer Entry Profile supplements the top-level process documents
7 (submitting-patches, submitting drivers...) wi 7 (submitting-patches, submitting drivers...) with
8 subsystem/device-driver-local customs as well 8 subsystem/device-driver-local customs as well as details about the patch
9 submission life-cycle. A contributor uses this 9 submission life-cycle. A contributor uses this document to level set
10 their expectations and avoid common mistakes; !! 10 their expectations and avoid common mistakes, maintainers may use these
11 profiles to look across subsystems for opportu 11 profiles to look across subsystems for opportunities to converge on
12 common practices. 12 common practices.
13 13
14 14
15 Overview 15 Overview
16 -------- 16 --------
17 Provide an introduction to how the subsystem o 17 Provide an introduction to how the subsystem operates. While MAINTAINERS
18 tells the contributor where to send patches fo 18 tells the contributor where to send patches for which files, it does not
19 convey other subsystem-local infrastructure an 19 convey other subsystem-local infrastructure and mechanisms that aid
20 development. 20 development.
21 21
22 Example questions to consider: 22 Example questions to consider:
23 23
24 - Are there notifications when patches are app 24 - Are there notifications when patches are applied to the local tree, or
25 merged upstream? 25 merged upstream?
26 - Does the subsystem have a patchwork instance 26 - Does the subsystem have a patchwork instance? Are patchwork state
27 changes notified? 27 changes notified?
28 - Any bots or CI infrastructure that watches t 28 - Any bots or CI infrastructure that watches the list, or automated
29 testing feedback that the subsystem uses to !! 29 testing feedback that the subsystem gates acceptance?
30 - Git branches that are pulled into -next? 30 - Git branches that are pulled into -next?
31 - What branch should contributors submit again 31 - What branch should contributors submit against?
32 - Links to any other Maintainer Entry Profiles 32 - Links to any other Maintainer Entry Profiles? For example a
33 device-driver may point to an entry for its 33 device-driver may point to an entry for its parent subsystem. This makes
34 the contributor aware of obligations a maint !! 34 the contributor aware of obligations a maintainer may have have for
35 other maintainers in the submission chain. 35 other maintainers in the submission chain.
36 36
37 37
38 Submit Checklist Addendum 38 Submit Checklist Addendum
39 ------------------------- 39 -------------------------
40 List mandatory and advisory criteria, beyond t 40 List mandatory and advisory criteria, beyond the common "submit-checklist",
41 for a patch to be considered healthy enough fo 41 for a patch to be considered healthy enough for maintainer attention.
42 For example: "pass checkpatch.pl with no error 42 For example: "pass checkpatch.pl with no errors, or warning. Pass the
43 unit test detailed at $URI". 43 unit test detailed at $URI".
44 44
45 The Submit Checklist Addendum can also include 45 The Submit Checklist Addendum can also include details about the status
46 of related hardware specifications. For exampl 46 of related hardware specifications. For example, does the subsystem
47 require published specifications at a certain 47 require published specifications at a certain revision before patches
48 will be considered. 48 will be considered.
49 49
50 50
51 Key Cycle Dates 51 Key Cycle Dates
52 --------------- 52 ---------------
53 One of the common misunderstandings of submitt 53 One of the common misunderstandings of submitters is that patches can be
54 sent at any time before the merge window close 54 sent at any time before the merge window closes and can still be
55 considered for the next -rc1. The reality is t 55 considered for the next -rc1. The reality is that most patches need to
56 be settled in soaking in linux-next in advance 56 be settled in soaking in linux-next in advance of the merge window
57 opening. Clarify for the submitter the key dat !! 57 opening. Clarify for the submitter the key dates (in terms rc release
58 week) that patches might be considered for mer !! 58 week) that patches might considered for merging and when patches need to
59 wait for the next -rc. At a minimum: 59 wait for the next -rc. At a minimum:
60 60
61 - Last -rc for new feature submissions: 61 - Last -rc for new feature submissions:
62 New feature submissions targeting the next m 62 New feature submissions targeting the next merge window should have
63 their first posting for consideration before 63 their first posting for consideration before this point. Patches that
64 are submitted after this point should be cle 64 are submitted after this point should be clear that they are targeting
65 the NEXT+1 merge window, or should come with 65 the NEXT+1 merge window, or should come with sufficient justification
66 why they should be considered on an expedite 66 why they should be considered on an expedited schedule. A general
67 guideline is to set expectation with contrib 67 guideline is to set expectation with contributors that new feature
68 submissions should appear before -rc5. 68 submissions should appear before -rc5.
69 69
70 - Last -rc to merge features: Deadline for mer 70 - Last -rc to merge features: Deadline for merge decisions
71 Indicate to contributors the point at which 71 Indicate to contributors the point at which an as yet un-applied patch
72 set will need to wait for the NEXT+1 merge w 72 set will need to wait for the NEXT+1 merge window. Of course there is no
73 obligation to ever accept any given patchset !! 73 obligation to ever except any given patchset, but if the review has not
74 concluded by this point the expectation is t !! 74 concluded by this point the expectation the contributor should wait and
75 resubmit for the following merge window. 75 resubmit for the following merge window.
76 76
77 Optional: 77 Optional:
78 78
79 - First -rc at which the development baseline 79 - First -rc at which the development baseline branch, listed in the
80 overview section, should be considered ready 80 overview section, should be considered ready for new submissions.
81 81
82 82
83 Review Cadence 83 Review Cadence
84 -------------- 84 --------------
85 One of the largest sources of contributor angs 85 One of the largest sources of contributor angst is how soon to ping
86 after a patchset has been posted without recei 86 after a patchset has been posted without receiving any feedback. In
87 addition to specifying how long to wait before 87 addition to specifying how long to wait before a resubmission this
88 section can also indicate a preferred style of 88 section can also indicate a preferred style of update like, resend the
89 full series, or privately send a reminder emai 89 full series, or privately send a reminder email. This section might also
90 list how review works for this code area and m 90 list how review works for this code area and methods to get feedback
91 that are not directly from the maintainer. 91 that are not directly from the maintainer.
92 92
93 Existing profiles 93 Existing profiles
94 ----------------- 94 -----------------
95 95
96 For now, existing maintainer profiles are list 96 For now, existing maintainer profiles are listed here; we will likely want
97 to do something different in the near future. 97 to do something different in the near future.
98 98
99 .. toctree:: 99 .. toctree::
100 :maxdepth: 1 100 :maxdepth: 1
101 101
102 ../doc-guide/maintainer-profile 102 ../doc-guide/maintainer-profile
103 ../nvdimm/maintainer-entry-profile 103 ../nvdimm/maintainer-entry-profile
104 ../arch/riscv/patch-acceptance <<
105 ../process/maintainer-soc <<
106 ../process/maintainer-soc-clean-dts <<
107 ../driver-api/media/maintainer-entry-profil <<
108 ../process/maintainer-netdev <<
109 ../driver-api/vfio-pci-device-specific-driv <<
110 ../nvme/feature-and-quirk-policy <<
111 ../filesystems/xfs/xfs-maintainer-entry-pro <<
112 ../mm/damon/maintainer-profile <<
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.