Hey, On Wed, Jul 19, 2023 at 11:32:25AM -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. Thanks for writing this up, it's great to have this stuff written down. I had one minor comment from reading through things... > +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 promptly. > +Even when a particular 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 response time will vary by subsystem. > +The patch review SLA the subsystem had set for itself can sometimes > +be found in the subsystem documentation. Failing that as a rule of thumb > +reviewers should try to respond quicker than what is the usual patch > +review delay of the subsystem maintainer. The resulting expectations > +may range from two working days for fast-paced subsystems (e.g. networking) > +to as long as a few weeks in slower moving parts of the kernel. > + > +Mailing list participation > +-------------------------- > +Reviews > +------- > +Refactoring and core changes > +---------------------------- > +Bug reports > +----------- ..I noticed that none of these sections address actually testing the code they're responsible for on a (semi-)regular basis. Sure, that comes as part of reviewing the patches for their code, but changes to other subsystems that a driver/feature maintainer probably would not have been CCed on may cause problems for the code they maintain. If we are adding a doc about best-practice for maintainers, I think we should be encouraging people to test regularly.
Attachment:
signature.asc
Description: PGP signature
