Re: NewNFS vs. oldNFS for 10.0?

Freddie Cash wrote:
> 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)
Actually, your numbering is out by one.
7.x - old only
8.x - old and new, with old default
9.x - old and new, with new default

I, personally, don't care if 10.x has both in it or not.
The only downside I see is that it often means generating patches for
both, but this usually occurs when the code in the old and new are
virtually identical (new cloned from old).

rick

> - 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