Date: Mon, 24 Jun 1996 14:09:57 -0600 From: Nate Williams <nate@sri.MT.net> To: Terry Lambert <terry@lambert.org> Cc: nate@sri.MT.net (Nate Williams), hackers@freefall.freebsd.org Subject: Re: cvs commit: src/etc/mtree BSD.usr.dist Message-ID: <199606242009.OAA21042@ws1.sri.MT.net> In-Reply-To: <199606241857.LAA28712@phaeton.artisoft.com> References: <199606241517.JAA20540@rocky.sri.MT.net> <199606241857.LAA28712@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > In case you hadn't noticed, the 'fsck' patch has been in current for > > almost a month now. The reason it wasn't put in was because I don't > > think anyone took enough time to understand the problem well enough, so > > therefore didn't want to 'break' the system if the patch didn't work. I > > gave up on trying to understand the problem (not enough time) and simply > > went with it hoping my testing was adequate. It *appears* to work, > > though if you asked me if I was sure it's the correct fix I couldn't > > answer with assurance. > > Probably need an FS expert -- do we have one of those on the list? > > -- hmmmmm... we do: me. I stated that I had regression tested the > fix. I did, including power-off destructive testing during latent > metadata update operations (see the debug sysctl in the source file > /sys/ufs/ffs/ffs_alloc.c). I did as well. But that still doesn't mean I understand it completely. Again, if I'm going to bring something into the tree, it's *MY BUTT* on the line if it breaks, so I tested it to the best of my ability. (My laptop makes a great test bed. :) [ Nomad laptop code ] > Question: did they submit the code as if it were integratable as is, > or like my SYSINIT code, was it a prototype? From what I can see > of their announcements, it was prototype code. It's patches against various releases, including the most recent 6/12 SNAP. That's pretty much 'integratable' assuming you buy that it's bug-free the way it sits. > > The 'boot-disk' code they use would be much *simpler* if they added 2 > > functions to the code and relegated all of the conditional code to it. > > (You should be able to use 1 additional function, but I'll grant 2). > > Instead of doing that there are modifications to *every* single file > > which makes the code bloat excessively, plus trying to understand it > > becomes more problematic. I've almost considered re-writing the Nomad > > code to remove these particular kludges, but I don't agree with how it's > > being done in the first place so it would only encourage using it. > > The same class of architectural arguments were the basis of some of the > patches I supplied; ironic, isn't it? 8-). *grin* > > What I've done recently is spend *ALOT* of time trying to sync. up our > > source trees. I've been sending patches back to Hosokawa with a set of > > diffs that can be applied to our -current tree to bring the Nomad code > > into the *exact* same functionality as their code, but with white-space > > and formatting changes removed. This way they can review their changes > > again to make sure they are valid (I question some of them), and allow > > us to at least have more commonality than before. Right now the code > > has diverged so much that integrating is near impossible, and if they > > diverge much more than I'm going to give up and roll everything myself > > from scratch. > > Look, this was not an attempt to denigrate the work you were putting > in, nor the cooperation. It *was* intended to point out the cycle > time involved -- nothing else. Agreed. But given the current state of affairs which unfortunately isn't going to change anytime soon, it's a necessary cost of doing business. Either we go the OpenBSD route (which is fraught with the perils of having the sources 'tainted' with bad code, thus causing the quality of the system to go downhill), or go the Linux route and have *one* person do all the code integration, which means that it's an all/nothing show. (I understand this has changed somewhat lately, and they now have a system more like our current system, where individuals 'own' parts of the tree.) > > This sounds harsh, but it's starting becoming *more* work > > to integrate their code than it would be for me to write it myself. > > It should be obvious that this would be a natural result of the > integration method used... this is perhaps more obvious to me, > because this is exactly what I suggested I was willing to do with > my own code to make it acceptable. > > I think it is unreasonable to believe that you must understand > everything in order to use work from third party providers; this > is not to say that you should accepts prototypes as of they were > production code; you should not. Probably, you should approach > them about high level issues, and leave the prototype to production > conversion to them. This is more difficult for you because of the > APM code being your baby, and integral to the use of their work. The APM code *became* my baby because I needed it working better in order to work on the other PC-CARD stuff. I started with somethin I felt I could take-on, and then worked my way into the other parts. (Enough horn-blowing, that's not the issue.) > Look on it as a collaborative effort, not a filtering effort, and > expect them to collaborate. I'm trying, but sometimes the colloboration has been difficult. They have an agenda that is completely separate from the FreeBSD agenda (as I understand it), so collabaration/integration isn't so easy. Fortunately for me, the FreeBSD Project (which has been Poul and I up till now) holds the 'big carrot'. We are the folks who 'bless' the code and bring it into FreeBSD when it passes muster. This is a 'big stick' which forces the developers to want to work with us, and I don't take that lightly. But, it also means that the Nomads are free to ignore the work that goes into the FreeBSD (partially because of my actions) and do their own thing, to the detriment of all users. So we share the responsibility to 'integrate' our code. Again, this isn't supposed to be 'the Nate story', but I'm trying to explain the similarities between the 'Nomad' code and your code, and my take on the matter from a 'integrators' viewpoint. > Use of "champions" to operate as filters is ineffective; if the > expertise (or interest) does not exist on the core team, than any > code which relies on this method for integration will fail to be > integrated. You got it. Welcome to the world of free software. So, you can do what Bruce does and write wonderfully long and descriptive explanations of his bug fixes that give us all warm and fuzzy feelings inside, plus he answers our sometimes annoying and sophmoric questions with great patience until we are convinced that it does what he says it does, or you can take the other tact and state 'I'm a x86 guru, and you should take what I say as law.'. Which developer would you rather work with? [ And again, a public thanks to Bruce for *ALL* the help he's provided over the years I've 'known' him, from Minix 1.4a -> FreeBSD-current. :) ] > > And, this is peanuts compared to your FS patches, your kernel locking > > patches, and the like. Also, the Nomad kernel code is already mostly > > broken up into functional chunks because of my previous integration > > efforts, so it's easy for me to separate out function from style. > > I wish that it were possible to change a VFS interface without impacting > everything that uses VFS interfaces, but it is not. > > I wish it were possible to ensure the state in and out of functions > without going to a style technique like single-entry/single-exit, > but it isn't -- without seriously damaging readability. Try. Try *really* hard. Try extra-ordinarily hard. And, when you've proven your point by co-operating, we can all be convinced that your way is the best way instead of lots of long email messages with hand-waving. > > However, this has taken my close to 6 months of my time working over 20 > > hours/week. For you to expect Poul (or any other developer) to commit > > to this much time is too much. I'm doing it because I got paid for part > > of it at work, and the last 2.5 months I've done it because I want to > > finish what I started. .. > > Again, not to denigrate your efforts, but the idea that all code must > be vetted by a core member expert in the code is ridiculous (and, > unless John H. has joined the core team without telling me, probably > an impossibly high standard to ever meet for some FS issues). No core members has to be involved, but some *committer* has to sponsor (champion) the code, and has to understand it 'enough' to take the heat for it. Each member has different thickness of Asbestos skin (Jordan seems to be the most thick-skinned given his tendency to integrate the most code. :) In any case, the committer has to feel safe, and no matter how wonderful your resume is, it's not going to happen 'off the bat'. As a matter of fact, I'd suspect that even John H. would go through a few rounds of 'code review' before he was given commit access. However, if you don't like the way it's being done , you can always start 'TerryBSD'. :) > > > I'm sure I could also halve or quarter my production, providing > > > rationale for things which are, to me at least, bloody obvious. I'm > > > already willing to spend a large amount of time parceling up my > > > work, but I have only so much time I'm willing to spend; please do > > > not bankrupt me. > > > > Please don't bankrupt the committers. For a committer to understand > > your code, they must become at least passingly familiar with both the > > problem, and the fix. So, it takes almost as long to 'commit' a fix as > > it does to create it. So, what may be 'bloody obvious' to you isn't so > > obvious to a committer. > > I am willing to explain issues in less than strictly technically > accurate terms to educate people to the level of passing familiarity; > but a number of my fixes require a full understanding of both the > existing code and John Heidemann's Master's Thesis to realize that > the deltas are designed to move the code as integrated by CSRG into > line with John's intended design. There are fixes which add *nothing* > to existing functionality, which seem like tangential and gratuitous > code rewrites, when they are, in fact, necessary prepatory work for > architectural next steps. But these 'next steps' don't have to be taken until we get there. In the same manner that I integrated those changes which I understood in the Nomad code (and left our almost all of the *next steps*) you must give us the 'first steps' only. Walk before running. :) > Some of the stuff people submit qualifies as PhD level work; I'd > say that most of the stuff John Dyson does falls into that category, > and there are others, which I won't ennumerate for fear of omitting > someone from the list. Unless these PhD's are already on the core > team, you are screwed: you can't expect to be able to incorporate > their work, ever. John Dyson didn't have commits priveledges for a long time (mostly due to connectivity problems), but I do know and trust his work. Also, long before he got commit privs, (and during), David reviewed his work, and vice-versa. Having 'one' expert is not enough. With the PC-CARD stuff, Poul reviews almost all of the patches I create myself as well as the Nomad stuff. Expecting us to 'trust you' is a luxury we don't even allow for ourselves. > > Until you've proven yourself to the responsible committer, you must > > *help* that person understand your code, which means putting up with > > his/her idiosyncracies necessary to get code integrated. > > I can buy this... to an extent. > I refuse, however, to educate them > to the point where they could be me. It is far too much effort, and, > I suspect, the primary reason John Dyson has yet to architecturally > document the VM system, except in broad strokes. Yet David has a pretty good idea how the system works through the help of John. And John has a pretty good idea how the system works via the help of David. > To do so would take a large effort, better turned toward coding, and a > level of detail which would significantly constrain the future > directions he would be allowed (by his peers) to take: anything > outside the plan would tend to be shot down. Contrast this to *NOT* educatin someone. You'll end up with either a completely new version of BSD (TerryBSD), or you're time and effort is a complete waste of your time *IF* your intention is that this code be integrated into a public release of FreeBSD or whatever. It's your call. Either you can comply with the system (I didn't say you had to like it), or you can refuse to comply and continue to diverge from the code base. > > And, once you've proven yourself over a period of time that you can be > > trusted to commit 'functional' code that doesn't contain 'stylistic' > > changes that *may* have function down the road, you become a committer > > on your own, able to break the tree at will like the rest of us. > > What is fundamentally wrong with taking the long view? What is wrong > with changes enabling future functionality? I simply do not understand > this. Because *I* don't trust that the code you wrote is any better than the code that is in the current system. Does this mean I don't trust you? Nope, but I don't trust the code that *I* write, hence anything that is significant is reviewed by an employee at SRI for busines work or by a FreeBSD committer for free stuff. When code gets complex, another set of eyes is *critical*. > Escaping a 3 month (quarterly report) or 6 month (middle management > review cycle) or 12 month (employee review cycle) horizion is what > pariticipating in a volunteer effort is all about. I think you've got a different idea about 'volunteer' effort than I do. I consider coding in a 'volunteer' effort as code that *I* get to write in areas that *I* want to write in. But, that doesn't mean that I no longer have responsibilities to my customers or my peers (in this case the other FreeBSD developers). > > But this responsibility has to be earned with trust, not with words and > > code. > > Pericles, how doest thou thine love approve? > > It would help if things were operated on an initial basis of trust rather > than one of distrust, wouldn't it? Then we would not have to engage a > "prove yourself to me" protocol before being able to trust anyone. How would it help? > Have you heard of the prisoner's dilemma? Yes, and I don't happen to buy into it's premises. Call me one of those 'Montana Red-necks' who distrust everyone. :) Nate ps. My email box is down in preparation for an OS upgrade, so I'll be basically off-line for the rest of day because my mail-reader is gone.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606242009.OAA21042>