On Thu, Jul 20, 2023 at 07:23:56PM +0100, Edward Cree wrote: > On 19/07/2023 19:32, 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. > > > > Reviewed-by: Andrew Lunn <andrew@xxxxxxx> > > Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > Reviewed-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> > > Reviewed-by: Mark Brown <broonie@xxxxxxxxxx> > > Reviewed-by: Leon Romanovsky <leonro@xxxxxxxxxx> > > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> > > --- > > Thanks for writing this. One question— > > > +Reviews > > +------- > > + > > +Maintainers must review *all* patches touching exclusively their drivers, > > +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. > > Does this apply even to "checkpatch cleanup patch spam", where other patches > sprayed from the same source (perhaps against other drivers) have already > been nacked as worthless churn? I've generally been assuming I can ignore > those, do I need to make sure to explicitly respond with typically a repeat > of what's already been said elsewhere? No, you can ignore them if you don't want to take them :)
