On Fri, 14 Jul 2023 06:36:41 +0200 Krzysztof Kozlowski wrote: > On 14/07/2023 00:34, Jakub Kicinski wrote: > > +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. > > Two weeks is the upper limit. > > > +Mailing list participation > > +-------------------------- > > + > > +Linux kernel uses mailing lists as the primary form of communication. > > +Maintainers must be subscribed and follow the appropriate subsystem-wide > > +mailing list. Either by subscribing to the whole list or using more > > +modern, selective setup like > > +`lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_. > > + > > +Maintainers must know how to communicate on the list (plain text, no invasive > > +legal footers, no top posting, etc.) > > + > > +Reviews > > +------- > > + > > +Maintainers must review *all* patches touching exclusively their drivers, > > I don't agree with this as a small driver maintainer. Several subsystem > maintainers take the patches much faster than I am able to check the > inbox. I can provide names if you need some proves. With such criteria I > should be removed from maintainers, because I am not able to review > within 24h. > > Either give reasonable time, like two weeks, or don't require driver > maintainers to be 24/7 for subystem maintainer disposal. This is very > unfair rule. I think your concern is more about the timeline than what's quoted here, so I rephrased that: -The exact expectations on the review time will vary by subsystem -from 1 day (e.g. networking) to a week in smaller subsystems. +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 to two weeks +in slower moving parts of the kernel. To the point of reviewing "all" patches, I want to keep this. When I ping vendors they often reply with "oh I didn't know I'm supposed to respond, the change looks good". People confuse the review process with a veto process, if they don't want to outright reject the change they stay quiet :| > > +no matter how trivial. If the patch is a tree wide change and modifies > > +multiple drivers - whether to provide a review is left to the maintainer. > > + > > +There should be multiple maintainers for any piece of code, an ``Acked-by`` > > +or ``Reviewed-by`` tag (or review comments) from a single maintainer is > > +enough to satisfy this requirement. > > + > > +If review process or validation for a particular change will take longer > > +than the expected review timeline for the subsystem, maintainer should > > +reply to the submission indicating that the work is being done, and when > > +to expect full results. > > + > > +Refactoring and core changes > > +---------------------------- > > + > > +Occasionally core code needs to be changed to improve the maintainability > > +of the kernel as a whole. Maintainers are expected to be present and > > +help guide and test changes to their code to fit the new infrastructure. > > + > > +Bug reports > > +----------- > > + > > +Maintainers must respond to and address bug reports. The bug reports > > This is even more unreasonable than previous 1 day review. I don't have > capabilities to address bug reports for numerous drivers I am > maintaining. I don't have hardware, I don't have time, no one pays me > for it. I still need some life outside of working hours, so expecting > both reviews in 1 day and addressing bugs is way too much. > > > +range from users reporting real life crashes, thru errors discovered > > +in fuzzing to reports of issues with the code found by static analysis > > +tools and new compiler warnings. > > + > > +Volunteer maintainers are only required to address bugs and regressions. > > "Only required"? That's not "only" but a lot. I was trying to soften the paragraph for volunteers let me try to soften it.. harder? > > +It is understood that due to lack of access to documentation and > > +implementation details they may not be able to solve all problems. > > So how do I address? Say "Oh, that's bad"? How about: Bug reports ----------- Maintainers must respond to bug reports of reasonable quality. The bug reports range from users reporting real life crashes, thru errors discovered in fuzzing to reports of issues with the code found by static analysis tools and new compiler warnings. It is understood that the hands of volunteer maintainers can often be tied by the lack of access to documentation, implementation details, hardware platforms, etc. I don't know how to phrase it better :( Obviously maintainers are expected to look at bug reports. At the same time we all know the feeling of being a maintainer of some crappy HW which sometimes doesn't work and all we can do is say "thoughts and prayers". IDK. The doc would be incomplete without mentioning that bug reports are part of maintainers' life :( > Jakub, with both of your criteria - reviewing and addressing - I should > be dropped from all the driver maintainership. If this document passes, > I will do it - drop myself - because: > 1. No one pays me for it, > 2. I barely have hardware, > 3. I want to live a life and I am already working much more than 8h per day. It's really hard to codify the rules. I hope we can start somewhere and chisel at the rules if/as we start getting feedback/complaints. I can give you examples of bad vendor behavior or people who stopped participating 10 years ago yet they still figure in MAINTAINERS all day. Next time I see a rando manager added as a maintainer I want to be able to point them at a document. If the document is too "soft" they will just wave it off :(
