Re: should we make --enable-tirpc the default in current nfs-utils?

[Steve Dickson <SteveD@redhat.com>]

Muntz, Daniel wrote:
>  
> 
>> -----Original Message-----
>> From: Jeff Layton [mailto:jlayton@redhat.com] 
>> Sent: Monday, June 08, 2009 10:00 AM
>> To: Muntz, Daniel
>> Cc: Chuck Lever; Mike Frysinger; linux-nfs@vger.kernel.org
>> Subject: Re: should we make --enable-tirpc the default in 
>> current nfs-utils?
>>
>> On Mon, 8 Jun 2009 08:46:23 -0700
>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>
>>>> The reason to build without it is that libtirpc is 
>> largely untested 
>>>> code (on Linux), and the nfs-utils support to use TI-RPC is also 
>>>> largely untested.  I think the default config settings should 
>>>> configure a safe, known-working configuration, not the 
>> most advanced 
>>>> configuration.
>>>>
>>>> As much as I like the idea of wider testing, the idea 
>> that we happen 
>>>> to be testing with live users is not inviting.  But I 
>> guess it's all 
>>>> we've got at this point.
>>> It would be nice if RH had a way of testing this with 
>> Fedora without 
>>> making it the default in the standard nfs-utils package 
>> until _after_ 
>>> testing.  Perhaps nfs-utils has evolved to the point where it could 
>>> use a release-candidate model.  Then all distros could pull an RC 
>>> build if they want it, while production users could pull 
>> the last "stable"
>>> release.
>> This has very little to do with Red Hat. We can enable or 
>> disable TIRPC in our own distros without making this change 
>> upstream. The question here is whether we should make this 
>> the default now, or does it make more sense to wait until 
>> everything has been converted to TIRPC, and had IPv6 support 
>> added and *then* enable it.
> 
> But **IF** you had a release candidate model, then you would have a
> mechanism for OTHERS to pick up "pre-release" code and get the
> additional testing you are after.  Without it, your only option is to
> put un/little-tested code into mainline nfs-utils (I am going on your
> assertion and Chuck's that this code needs more testing).  I can't see
> any reasonable excuse (non-FUD as you say) for not doing things this
> way.
> 
hmm.. this is an interesting idea... I do create tags in
the git tree that are a collection of commits... So I guess
those could be come rc releases... but I'm not sure how 
I could package them or even if they should be packaged... 

I guess I could do what I'm doing with the nfs41 and pNFS
code and have development yum reposes, but its an Fedora only
thing so its not clear how useful it would be...

steved.