Date: Mon, 13 Nov 1995 19:52:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@rocky.sri.MT.net (Nate Williams) Cc: terry@lambert.org, henrich@crh.cl.msu.edu, nate@rocky.sri.MT.net, freebsd-current@FreeBSD.ORG Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511140252.TAA18662@phaeton.artisoft.com> In-Reply-To: <199511140144.SAA01129@rocky.sri.MT.net> from "Nate Williams" at Nov 13, 95 06:44:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [ Reviewing the VM patch and not bringing it into 2.1 ] > > > I find it hard to believe too, since all that is required is that you > > understand the code. Matt clearly had to do this to generate the > > patches in the first place, and we must assume that the people who > > wrote it understand it enough to predict the results. > > Gee, and I suspect you've never written a bad patch before. Geeze > folks, let's get real now. We were discussing the difficulty of reviewing a patch, not whether or not the results of that review would be "bad patch' or "good patch". > > It's not like this is magic or anything... it's complex, yes, but that > > doesn't make it beyond mortal ken. > > It also doesn't mean that the patch is bad, but *BECAUSE* it is complex > it is often difficult to miss subtle features (as you have shown in the > past :]) and necessary code to get things working right. Even your FS > patches were missing some critical things. If they would have been > committed as submitted, FS corruption and/or panics *would* have > occurred. > > Does this mean you didn't understand all of the issues? Maybe *grin*, > but I'll bet it means you're human more than anything else. I'll bet it's because I initially did them against 2.0.5 and the code changed sufficiently going to -current that I missed some of the patch changes that were necessary because of the code changes to -current. And then I'll bet I screwed up hand-applying the patches to the patches for -current (*that* showed I was human). And it's quite questionable whether the *way* in which read-only FS handling changed (and broke application of my patches) is actually the precise fix for the problem that it attmpted to address (though I readily admit something like it was necessary for translucent/union FS operation with one R/O and one R/W FS overlaid. And I'll bet that I've taken steps to allow me to maintain correct CVS revisions so that that won't happen ever again. The patches I make from now on will cleanly apply against the files whose ID's match the files from which the patches were generated (the same was true before, but now I will be submitting whole files with intact tags so an integrator can 'cvs merge' against the correct tags). The level of abstraction in the two patch sets is definitely not equal; the Dillon patches touch far, far fewer files. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511140252.TAA18662>