On Thu, Jul 13, 2023 at 03:34:32PM -0700, Jakub Kicinski wrote: > We appear to have a gap in our process docs. We go into detail > on how to contribute code to the kernel, and how to be a subsystem > maintainer. I can't find any docs directed towards the thousands > of small scale maintainers, like folks maintaining a single driver > or a single network protocol. > > Document our expectations and best practices. I'm hoping this doc > will be particularly useful to set expectations with HW vendors. > > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> > --- > Please consider this more of a draft than a statement of my opinion. > IOW prefer suggesting edits over arguing about correctness, hope > that makes sense. This looks great to me, thanks for putting it together. But I do have one objection on the timeline portion: > --- > .../feature-and-driver-maintainers.rst | 159 ++++++++++++++++++ > Documentation/maintainer/index.rst | 1 + > 2 files changed, 160 insertions(+) > create mode 100644 Documentation/maintainer/feature-and-driver-maintainers.rst > > diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst > new file mode 100644 > index 000000000000..ee8ccc22b16a > --- /dev/null > +++ b/Documentation/maintainer/feature-and-driver-maintainers.rst > @@ -0,0 +1,159 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +============================== > +Feature and driver maintainers > +============================== > + > +The term "maintainer" spans a very wide range of levels of engagement > +from people handling patches and pull requests as almost a full time job > +to people responsible for a small feature or a driver. > + > +Unlike most of the chapter, this section is meant for the latter (more > +populous) group. It provides tips and describes the expectations and > +responsibilities of maintainers of a small(ish) section of the code. > + > +Driver and alike most often do not have their own mailing lists and > +git trees but instead send and review patches on the list of a larger > +subsystem. > + > +Responsibilities > +================ > + > +The amount of maintenance work is usually proportional to the size > +and popularity of the code base. Small features and drivers should > +require relatively small amount of care and feeding. Nonetheless > +when the work does arrive (in form of patches which need review, > +user bug reports etc.) it has to be acted upon very promptly. > +Even when single driver only sees one patch a month, or a quarter, > +a subsystem could well have a hundred such drivers. Subsystem > +maintainers cannot afford to wait a long time to hear from reviewers. > + > +The exact expectations on the review time will vary by subsystem > +from 1 day (e.g. networking) to a week in smaller subsystems. "to a few weeks". I can't do 1 day, or even 1 week for the subsystems I maintain (especially during merge windows or vacations.) How about that line being: from 1 day (e.g. networking) to a few weeks for smaller subsystems. And then add a link to "For specific subsystem response times, please see the document in [insert link here to where we keep the subsystem expectations]" And yeah, I do need to go add some process/maintainer-* files for the subsystems I maintain, it might be a good idea to also say that any new subsystems also provide this so we can start catching up on that. thanks, greg k-h
