On Jun 9, 2009, at 8:35 AM, Steve Dickson wrote:
Chuck Lever wrote:
On Jun 8, 2009, at 12:59 PM, Jeff Layton wrote:
On Mon, 8 Jun 2009 08:46:23 -0700
"Muntz, Daniel" <Dan.Muntz@xxxxxxxxxx> 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.
I disagree.
The question about changing the upstream default came up because I
asked
RH to enable this option in Fedora so we can test first. Steve
doesn't
want Fedora to enable TI-RPC unless upstream has it enabled by
default.
So this is _precisely_ about why RH won't enable this in Fedora
first.
My concern, as with all package maintainers, is to keep their package
or git tree or whatever as stable as possible so as not to have a
negative on his or her community users....
So my reluctance to make the switch in the Fedora Development stream,
called Rawhide, came from the concern of breaking the NFS components
what would have (as it has have) a very negative effect on entire
development of the next release (in this case F-12).
There must be something I don't understand. Why would we foist
something on all distributions (by placing it in upstream) that you
wouldn't even put in a development distribution? My impression was
that this kind of testing was exactly the purpose of rawhide and
Fedora. Is user space NFS special in this regard? If so, how can we
make progress if testing opportunities like this are not available to
user space NFS?
At this point Jeff has convinced me there really aren't any practical
testing opportunities we can use before this is enabled upstream
anyway. So, go ahead and enable TI-RPC by default upstream. Jeff's
patch from yesterday seems fine.
So I like to "Bake" things in upstream for a while, to see how things
go. Because in the end, the people who are pulling directly from the
git tree generally have clue and are very easy to work with because
of their strong understanding of what they are doing...
Once it appears the new functionality somewhat "baked", I will gladly
introduce the functionality into rawhide, which enables testing by
a much broader community... which is a very good thing...
I have found that this theory has worked fairly well in the all
the packages I maintain.... Not to say things don't break... Just
ask the Fedora community about the time I broke mount.. My IRC
window lit up so fast I thought it was on fire! 8-)
What this tells me is that our own pre-commit testing of nfs-utils is
not adequate. I do not exclude myself from this observation.
So in the end, its not the case I won't enable it, I just want to
take as many precautions as I can to ensure both streams, upstream
and rawhide stay as stable as possible...
Yes, I would also like upstream to be as stable as possible, which is
why I have voiced a preference for more testing before the existing TI-
RPC work goes upstream. The practical world wins out, however.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
