Documentation/maintainer/feature-and-driver-maintainers.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 ==============================
   4 Feature and driver maintainers
   5 ==============================
   6
   7 The term "maintainer" spans a very wide range of levels of engagement
   8 from people handling patches and pull requests as almost a full time job
   9 to people responsible for a small feature or a driver.
  10
  11 Unlike most of the chapter, this section is meant for the latter (more
  12 populous) group. It provides tips and describes the expectations and
  13 responsibilities of maintainers of a small(ish) section of the code.
  14
  15 Drivers and alike most often do not have their own mailing lists and
  16 git trees but instead send and review patches on the list of a larger
  17 subsystem.
  18
  19 Responsibilities
  20 ================
  21
  22 The amount of maintenance work is usually proportional to the size
  23 and popularity of the code base. Small features and drivers should
  24 require relatively small amount of care and feeding. Nonetheless
  25 when the work does arrive (in form of patches which need review,
  26 user bug reports etc.) it has to be acted upon promptly.
  27 Even when a particular driver only sees one patch a month, or a quarter,
  28 a subsystem could well have a hundred such drivers. Subsystem
  29 maintainers cannot afford to wait a long time to hear from reviewers.
  30
  31 The exact expectations on the response time will vary by subsystem.
  32 The patch review SLA the subsystem had set for itself can sometimes
  33 be found in the subsystem documentation. Failing that as a rule of thumb
  34 reviewers should try to respond quicker than what is the usual patch
  35 review delay of the subsystem maintainer. The resulting expectations
  36 may range from two working days for fast-paced subsystems (e.g. networking)
  37 to as long as a few weeks in slower moving parts of the kernel.
  38
  39 Mailing list participation
  40 --------------------------
  41
  42 Linux kernel uses mailing lists as the primary form of communication.
  43 Maintainers must be subscribed and follow the appropriate subsystem-wide
  44 mailing list. Either by subscribing to the whole list or using more
  45 modern, selective setup like
  46 `lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_.
  47
  48 Maintainers must know how to communicate on the list (plain text, no invasive
  49 legal footers, no top posting, etc.)
  50
  51 Reviews
  52 -------
  53
  54 Maintainers must review *all* patches touching exclusively their drivers,
  55 no matter how trivial. If the patch is a tree wide change and modifies
  56 multiple drivers - whether to provide a review is left to the maintainer.
  57
  58 When there are multiple maintainers for a piece of code an ``Acked-by``
  59 or ``Reviewed-by`` tag (or review comments) from a single maintainer is
  60 enough to satisfy this requirement.
  61
  62 If the review process or validation for a particular change will take longer
  63 than the expected review timeline for the subsystem, maintainer should
  64 reply to the submission indicating that the work is being done, and when
  65 to expect full results.
  66
  67 Refactoring and core changes
  68 ----------------------------
  69
  70 Occasionally core code needs to be changed to improve the maintainability
  71 of the kernel as a whole. Maintainers are expected to be present and
  72 help guide and test changes to their code to fit the new infrastructure.
  73
  74 Bug reports
  75 -----------
  76
  77 Maintainers must ensure severe problems in their code reported to them
  78 are resolved in a timely manner: regressions, kernel crashes, kernel warnings,
  79 compilation errors, lockups, data loss, and other bugs of similar scope.
  80
  81 Maintainers furthermore should respond to reports about other kinds of
  82 bugs as well, if the report is of reasonable quality or indicates a
  83 problem that might be severe -- especially if they have *Supported*
  84 status of the codebase in the MAINTAINERS file.
  85
  86 Selecting the maintainer
  87 ========================
  88
  89 The previous section described the expectations of the maintainer,
  90 this section provides guidance on selecting one and describes common
  91 misconceptions.
  92
  93 The author
  94 ----------
  95
  96 Most natural and common choice of a maintainer is the author of the code.
  97 The author is intimately familiar with the code, so it is the best person
  98 to take care of it on an ongoing basis.
  99
 100 That said, being a maintainer is an active role. The MAINTAINERS file
 101 is not a list of credits (in fact a separate CREDITS file exists),
 102 it is a list of those who will actively help with the code.
 103 If the author does not have the time, interest or ability to maintain
 104 the code, a different maintainer must be selected.
 105
 106 Multiple maintainers
 107 --------------------
 108
 109 Modern best practices dictate that there should be at least two maintainers
 110 for any piece of code, no matter how trivial. It spreads the burden, helps
 111 people take vacations and prevents burnout, trains new members of
 112 the community etc. etc. Even when there is clearly one perfect candidate,
 113 another maintainer should be found.
 114
 115 Maintainers must be human, therefore, it is not acceptable to add a mailing
 116 list or a group email as a maintainer. Trust and understanding are the
 117 foundation of kernel maintenance and one cannot build trust with a mailing
 118 list. Having a mailing list *in addition* to humans is perfectly fine.
 119
 120 Corporate structures
 121 --------------------
 122
 123 To an outsider the Linux kernel may resemble a hierarchical organization
 124 with Linus as the CEO. While the code flows in a hierarchical fashion,
 125 the corporate template does not apply here. Linux is an anarchy held
 126 together by (rarely expressed) mutual respect, trust and convenience.
 127
 128 All that is to say that managers almost never make good maintainers.
 129 The maintainer position more closely matches an on-call rotation
 130 than a position of power.
 131
 132 The following characteristics of a person selected as a maintainer
 133 are clear red flags:
 134
 135  - unknown to the community, never sent an email to the list before
 136  - did not author any of the code
 137  - (when development is contracted) works for a company which paid
 138    for the development rather than the company which did the work
 139
 140 Non compliance
 141 ==============
 142
 143 Subsystem maintainers may remove inactive maintainers from the MAINTAINERS
 144 file. If the maintainer was a significant author or played an important
 145 role in the development of the code, they should be moved to the CREDITS file.
 146
 147 Removing an inactive maintainer should not be seen as a punitive action.
 148 Having an inactive maintainer has a real cost as all developers have
 149 to remember to include the maintainers in discussions and subsystem
 150 maintainers spend brain power figuring out how to solicit feedback.
 151
 152 Subsystem maintainers may remove code for lacking maintenance.
 153
 154 Subsystem maintainers may refuse accepting code from companies
 155 which repeatedly neglected their maintainership duties.