> -----Original Message-----
> From: Jeff Layton [mailto:[email protected]]
> Sent: Monday, June 08, 2009 4:08 PM
> To: Muntz, Daniel
> Cc: Chuck Lever; Mike Frysinger; [email protected]
> Subject: Re: should we make --enable-tirpc the default in
> current nfs-utils?
>
> On Mon, 8 Jun 2009 15:17:55 -0700
> "Muntz, Daniel" <[email protected]> wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Jeff Layton [mailto:[email protected]]
> > > Sent: Monday, June 08, 2009 10:00 AM
> > > To: Muntz, Daniel
> > > Cc: Chuck Lever; Mike Frysinger; [email protected]
> > > Subject: Re: should we make --enable-tirpc the default in current
> > > nfs-utils?
> > >
> > > On Mon, 8 Jun 2009 08:46:23 -0700
> > > "Muntz, Daniel" <[email protected]> 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.
> >
>
> I'm not sure what you're proposing...so you're saying we
> should cut a release candidate version and apply nothing but
> this patch to it to make --enable-tirpc the default? Or is
> this more a proposal to change the nfs-utils release mode in general?
>
> I'm a bit skeptical that that will result in better testing,
> but I'm willing to listen to what you're proposing.
Yes, I'm suggesting changing the release model for nfs-utils to be
similar to the kernel. Do release candidates with new functionality
that can be picked up by anyone for testing (or inclusion in Fedora, or
any other distro that wants to pick up new, but not necessarily stable
functionality), and then declare a stable release after the RC(s)
converge on stability.
Without picking on any particular area, there are a number of things
that come to mind that we might have caught in an RC, that were instead
caught in production environments because there's no distinction between
a stable nfs-utils release and one that needs more testing.
I suppose one could argue that this would result in less testing in the
sense that such a model should make it less likely that testing occurs
in production, however I'll assert that is "good". Distros like Fedora,
and people who want to run on the bleeding edge (Gentoo) can pull the
latest RC, and testing will occur there.
>
> When I say that this code needs more testing, I mean exactly that.
> Chuck and I have tested it and banged out as many bugs as we can find.
> The next step is to get it into more people's hands. This
> will likely uncover even more bugs, which we will then fix.
>
> --
> Jeff Layton <[email protected]>
>