Received-SPF: pass (google.com: domain of linux-nfs+bounces-461-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <bc48cb89-e1e2-44c9-8a99-61de8ab0fa57@redhat.com>
Date: Fri, 8 Dec 2023 05:53:48 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] autoconf: don't build nfsdcltrack by default
Content-Language: en-US
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-nfs@vger.kernel.org
References: <20231127-master-v1-1-5786ec1c6d38@kernel.org>
 <2c9be16b-012e-4438-a396-fd1050284310@redhat.com>
 <5e8863edb88f2bf5a2913736fbd71228fc986a5a.camel@kernel.org>
From: Steve Dickson <steved@redhat.com>
In-Reply-To: <5e8863edb88f2bf5a2913736fbd71228fc986a5a.camel@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hey

On 12/7/23 3:14 PM, Jeff Layton wrote:
> On Thu, 2023-12-07 at 14:42 -0500, Steve Dickson wrote:
>> Hey Jeff!
>>
>> On 11/27/23 10:18 AM, Jeff Layton wrote:
>>> Now that we've started the process to remove legacy v4 client tracking
>>> methods, let's stop building nfsdcltrack by default.
>>>
>>> Signed-off-by: Jeff Layton <jlayton@kernel.org>
>>> ---
>>>    configure.ac | 4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 93a1202807ea..62c833cc2409 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -248,9 +248,9 @@ AC_ARG_ENABLE(nfsrahead,
>>>    	fi
>>>    
>>>    AC_ARG_ENABLE(nfsdcltrack,
>>> -	[AS_HELP_STRING([--disable-nfsdcltrack],[disable NFSv4 clientid tracking programs @<:@default=no@:>@])],
>>> +	[AS_HELP_STRING([--enable-nfsdcltrack],[enable NFSv4 clientid tracking programs @<:@default=no@:>@])],
>>>    	enable_nfsdcltrack=$enableval,
>>> -	enable_nfsdcltrack="yes")
>>> +	enable_nfsdcltrack="no")
>>>    
>>>    AC_ARG_ENABLE(nfsv4server,
>>>    	[AS_HELP_STRING([--enable-nfsv4server],[enable support for NFSv4 only server  @<:@default=no@:>@])],
>>>
>>> ---
>>> base-commit: cc5cccbb9f24a2324f50a5cb4c29d83fdf6b1f90
>>> change-id: 20231127-master-5ef1c15da9c4
>>>
>>> Best regards,
>> Quick Question... Should we remove the code or just
>> turn off the building as this patch does?
>>
>> steved.
>>
> 
> Eventually, I think we'll want to remove nfsdcltrack entirely, but I
> think we shouldn't do that right away, without announcing it first and
> giving distros some warning.
> 
> Since we're on the subject, how long should we wait before fully
> deprecating it? A year? 2 or 3 releases? What makes sense?
Well, I was planning on make a new release (nfs-utils-2-7-1) when
I took the patch... So I guess turning the build off for
now makes sense... just to see what happens.

> 
> Maybe we should have configure spew a warning about its impending
> removal when someone enables it too?
Hmm... If it is not needed... why go through the effort?
I've always been a fan of... a clean cut! :-)

steved.