1 .. _maintainerentryprofile:
2
3 Maintainer Entry Profile
4 ========================
5
6 The Maintainer Entry Profile supplements the t
7 (submitting-patches, submitting drivers...) wi
8 subsystem/device-driver-local customs as well
9 submission life-cycle. A contributor uses this
10 their expectations and avoid common mistakes;
11 profiles to look across subsystems for opportu
12 common practices.
13
14
15 Overview
16 --------
17 Provide an introduction to how the subsystem o
18 tells the contributor where to send patches fo
19 convey other subsystem-local infrastructure an
20 development.
21
22 Example questions to consider:
23
24 - Are there notifications when patches are app
25 merged upstream?
26 - Does the subsystem have a patchwork instance
27 changes notified?
28 - Any bots or CI infrastructure that watches t
29 testing feedback that the subsystem uses to
30 - Git branches that are pulled into -next?
31 - What branch should contributors submit again
32 - Links to any other Maintainer Entry Profiles
33 device-driver may point to an entry for its
34 the contributor aware of obligations a maint
35 other maintainers in the submission chain.
36
37
38 Submit Checklist Addendum
39 -------------------------
40 List mandatory and advisory criteria, beyond t
41 for a patch to be considered healthy enough fo
42 For example: "pass checkpatch.pl with no error
43 unit test detailed at $URI".
44
45 The Submit Checklist Addendum can also include
46 of related hardware specifications. For exampl
47 require published specifications at a certain
48 will be considered.
49
50
51 Key Cycle Dates
52 ---------------
53 One of the common misunderstandings of submitt
54 sent at any time before the merge window close
55 considered for the next -rc1. The reality is t
56 be settled in soaking in linux-next in advance
57 opening. Clarify for the submitter the key dat
58 week) that patches might be considered for mer
59 wait for the next -rc. At a minimum:
60
61 - Last -rc for new feature submissions:
62 New feature submissions targeting the next m
63 their first posting for consideration before
64 are submitted after this point should be cle
65 the NEXT+1 merge window, or should come with
66 why they should be considered on an expedite
67 guideline is to set expectation with contrib
68 submissions should appear before -rc5.
69
70 - Last -rc to merge features: Deadline for mer
71 Indicate to contributors the point at which
72 set will need to wait for the NEXT+1 merge w
73 obligation to ever accept any given patchset
74 concluded by this point the expectation is t
75 resubmit for the following merge window.
76
77 Optional:
78
79 - First -rc at which the development baseline
80 overview section, should be considered ready
81
82
83 Review Cadence
84 --------------
85 One of the largest sources of contributor angs
86 after a patchset has been posted without recei
87 addition to specifying how long to wait before
88 section can also indicate a preferred style of
89 full series, or privately send a reminder emai
90 list how review works for this code area and m
91 that are not directly from the maintainer.
92
93 Existing profiles
94 -----------------
95
96 For now, existing maintainer profiles are list
97 to do something different in the near future.
98
99 .. toctree::
100 :maxdepth: 1
101
102 ../doc-guide/maintainer-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.