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 < [email protected] > > wrote: > > > On 15 March 2013 11:11, Alfred Perlstein < [email protected] > 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 > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to " > [email protected] " > > > > -- > Freddie Cash > [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]"
