Re: NewNFS vs. oldNFS for 10.0?

Isn't the general process (or at least past pattern) to:
  - have 1 release cycle with just the old code (aka 8.x with oldNFS)
  - have 1 release cycle with old and new code, default to old (aka 9.x
with oldNFS + newNFS)
  - have 1 release cycle with old and new code, default to new (aka 10.x
with newNFS)
  - remove the old code from next release (aka 11.0)

Or is that too long of a time-frame to migrate from old to new?



On Fri, Mar 15, 2013 at 11:46 AM, Adrian Chadd <adrian_at_freebsd.org> wrote:

> On 15 March 2013 11:11, Alfred Perlstein <bright_at_mu.org> wrote:
>
> > People in my org have been working with NFS and reporting issues for the
> > past year.  I'm quite certain that Doug White has reported issues due to
> > missing certain caching features of the old code.
> >
> > This is not indicative that newNFS is bad, just that it still needs some
> > work.
>
> Good news. and yes, it needs more work, but it doesn't preclude it
> from having a cutover date set. Even if that date is something far in
> the future, like 11.0.
>
> Or we'll just end up with two NFS stacks for some undetermined amount of
> time.
>
> > Sure, and how much NFS do you actually use and support exactly?
>
> .. and exactly how much would that lend to this discussion?
>
> I'm not arguing NFS technical details, I'm arguing project forward
> thinking and planning. These don't need me to be waist deep in NFS, it
> needs a broader view of how things may and may not go.
>
> I lived through the pain of Linux having multiple NFS implementations
> for precisely this reason. It was a clusterfsck of a nightmare of epic
> proportions. We should avoid that.
>
>
>
> adrian
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>



-- 
Freddie Cash
fjwcash_at_gmail.com