Date: Mon, 24 Jun 1996 09:17:01 -0600 From: Nate Williams <nate@sri.MT.net> To: Terry Lambert <terry@lambert.org> Cc: hackers@freefall.freebsd.org Subject: Re: cvs commit: src/etc/mtree BSD.usr.dist Message-ID: <199606241517.JAA20540@rocky.sri.MT.net> In-Reply-To: <199606240535.WAA27042@phaeton.artisoft.com> References: <5288.835493006@critter.tfs.com> <199606240535.WAA27042@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > In addition, the other patches I have submitted that *did* meet your > seperability and documentation criteria (the fsck root inode count > fix, the NFS server locking support patches, etc.) have *not* been > integrated. 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. > patches accepted. I am *not* the only person in this boat. It > takes nearly Herculean effort to get some types of patches accepted; > several groups have had to go so far as to offer their own boot > disks and patch kits (most notably Hosokawa-san's PCCARD code). > Even with Nate's patronage, there is still the need for building > seperate-from-snap boot disks to address a number of issues, because > the patches are not *truly* integrated. And won't be. The Nomad code is *full* of hacks and kludges (admitted by Hosokawa). My goal is to remove as many of those from the base system code and *then* add them back 'as necessary', rather than importing them wholesale and trying to work around them. My recent 'fix' to allow you to use 'generic' IRQ's in the code made the user-land code smaller, while the Nomad code adds 4-5K of completely un-necessary code which also makes the code more difficult to understand. Its taken my weeks to understand small portions of the code (not all due to them), and rather than continuing on in this manner I feel that it's better to make what we have more understandable and maintainable than chock-full of features that may/may not be correctly implemented. 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. 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. This sounds harsh, but it's starting becoming *more* work to integrate their code than it would be for me to write it myself. 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. 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. > 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. Remember, none of us are paid FS hackers in our day jobs, and *some* of the code that has been submitted in the past has been full of 'stylistic' and other misc. changes that are considered unacceptable. 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. 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. But this responsibility has to be earned with trust, not with words and code. > Can we compromise? Can you define how small is palletable so that I > can preinsure palletability before sending something, and if, when > I send something, it is not sufficient self explanatory (with a minimum > of accompanying text), tell me *that* so I can correct it? Finally, let me say that I hope you appreciate the work Poul is doing. I wouldn't even *begin* to start trying to integrate the code you're submitting. I looked at it *once*, and I was unable to separate out the functionality from the rest, and even if I was I wouldn't know if the changes were valid or not. Both the project and you win if we can get your *fixes* in the tree. But both you and the project lose if you continue to send in 'mega-commits' which are continually rejected, since the liklihood of integration become less each time for both personal and technical reasons. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606241517.JAA20540>