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

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Sep 22, 2025 at 10:29:11AM -0400, Chuck Lever wrote:
> 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".

TBH I think this ought to be in SubmittingPatches, "make this change"
helps nobody.

> 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.

/me notes that over in xfsland, I have a script that tries to guess the
correct "Cc: stable@vger.kernel.org # VERSION" and "Fixes:" tags for a
given diff, so I send them in the initial patch submission.  Obviously I
check the guesswork before sending.

--D

> 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