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