Re: [RFC PATCH] NFSD: Add a subsystem policy document

[Chuck Lever <cel@kernel.org>]

Hi Neil -

On 9/21/25 9:25 PM, NeilBrown wrote:
>> +Patch preparation
>> +~~~~~~~~~~~~~~~~~
>> +Like all kernel submissions, please use tagging to identify all
>> +patch authors. Reviewers and testers can be added by replying to
>> +the email patch submission. Email is extensively used in order to
>> +publicly archive review and testing attributions, and will be
>> +automatically inserted into your patches when they are applied.
>> +
>> +The patch description must contain information that does not appear
>> +in the body of the diff. The code should be good enough to tell a
>> +story -- self-documenting -- but the patch description needs to
>> +provide rationale ("why does NFSD benefit from this change?") or
>> +a clear problem statement ("what is this patch trying to fix?").

> These paras look to be completely generic - not at all nfsd-specific.
> Do they belong here?

Can you clarify which paragraphs you mean, exactly? Maybe the whole
section?

For context:

IMHO these comments aren't necessarily generic because I haven't seen
them in other documents, and we seem to get a lot of patches where the
description is just "Make this change".

The comments about tagging: I think other subsystems might not mind
seeing Cc: stable in the initial submission. NFS maintainers (even on
the client side) like to add those themselves.

I'd like to encourage contributors to get the Fixes: tag right before
submitting, too. It saves me a little incremental time per patch.

And, some of this text was cribbed from netdev's policy document, not
from a generic document, suggesting these are subsystem addendums.


> I expect more of a patch description than is given here.  I agree that
> "code should be good enough to tell a store" but I don't think that a
> patch can by itself be good enough.
> So I think that a patch description should describe the patch -
> particularly how the various changes in the patch relate.
> 
> With a good patch description, I should be able to then read the patch
> and every change will make sense in the context provided by the
> description.  It isn't just "Why", it is also "how".

I can add these remarks.


-- 
Chuck Lever