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

[Chuck Lever <cel@kernel.org>]

On 9/23/25 5:44 PM, Darrick J. Wong wrote:
>> (And above, snipped out, the "Key Cycle Dates" section title comes
>> from Documentation/maintainer/maintainer-entry-profile.rst. I'll
>> think of a more accurate section title).

> <shrug> Or you could define some key cycle dates.  Do you want to
> require that new feature patchsets must be in the review pipeline before
> -rc2 so that you can put whatever passes review into for-next just after
> -rc4?  Or specify that bugfixes completing review after -rc6 will just
> get rolled into the next merge window?

Hi Darrick, thanks for the comments.

For the past couple of years I've tried nailing patch submission to
the -rc cadence, but I've found it confusing and full of exception
processing. So I'm trying this out now:

nfsd-testing is always open. Patches are applied when we get "enough"
reviews and discussion. ("Then a miracle occurs.") Patches are dropped
if we find breakage or other problems.

After a patch has soaked for some period (right now, 3-4 weeks) it is
moved to nfsd-next.

Whatever is in nfsd-next gets sent to Linus during a merge window.

When the merge window closes, nfsd-next is renamed nfsd-fixes and a
new nfsd-next is created, based on -rc1. I think this is the only bit
that depends on a release candidate.

Any -rc fixes go through nfsd-testing, get applied to nfsd-fixes, and
then go to Linus. But I limit those, typically, to dire situations
and fixes for stuff that broke during the most recent upstream merge.

(Looks like I forgot to add the nfsd-fixes part to the document).


-- 
Chuck Lever