Date: Sat, 22 Jun 1996 17:26:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@freebsd.org (Poul-Henning Kamp) Cc: terry@lambert.org, alk@Think.COM, hackers@freefall.freebsd.org Subject: Re: cvs commit: src/etc/mtree BSD.usr.dist Message-ID: <199606230026.RAA23261@phaeton.artisoft.com> In-Reply-To: <4954.835483765@critter.tfs.com> from "Poul-Henning Kamp" at Jun 22, 96 03:49:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Terry, with all these strong ideas about How The World Should Be According > To Terry, I'm surprised that I still don't see patches from you. > > Poul-Henning > > PS: > Let me clarify what I mean by patch in this context, since past experience > have shown that you don't understand this concept: > > A patch is a file that containes: > 1. Readable english explanation of what this patch does, > in sufficient detail that people can review the changes. > One patch will do one thing, Ie, don't mix several changes > into one patch file. > > 2. Precise decription of the code version that is the reference > for this patch. > > 3. Input suitable for the patch(1), such that when applied to > the code base described in 2, it will apply cleanly. The sword of Damocles which you attempt to hang has two edges; let's get the trite flaming out of the way, and get down to brass tacks. --- BEGIN TRITE FLAMING ------------------------------------------------ Poul, with these strong ideas about Who And How People Should Be Allowed To Participate In Supposedly Public Participation Projects According To Poul, I'm suprised that I still don't see a willingness from you to meet people half way. Terry PS: Let me clarify what I mean by a willingness to meet people half way in this context, since past experience has shown you are unlear on the concept of compromise: A willingness to meet people half way includes: 1. Timely integration of patches when they are provided so they do not grow from single-effect modules into multiheaded monsters, or result in the expectation that the researcher will stop all future work, on a request/response basis, where you control what they are and are not allowed to do. 2. Provision of tools that operate in line with your philosophy instead of expecting people to spend their time reintegrating their code each time you do deign to respond to a request other than one from the person involved. 3. Do not allow the non-inclusion of past effort to prevent future effort, as in the failure to integrate the Lite 2 changes, which meet your above criteria, yet have lain fallow for a period in excess of a year. --- END TRITE FLAMING -------------------------------------------------- Poul, I do not claim total innocence in your obvious dislike for the code that I have provided you, since I *did* intentionally continue to change code rather than waiting for you to integrate the code code provided in palletably small chunks. In my opinion, you were taking too damn long, and you were an obstacle to me pursuing my goals. Like most obstacles in my life, I boarded my steam-roller, and proceeded in the straighest line to my goal, come hell or high water, with the result that I offended your sensibilities. If so, I'm sorry. But They Were In My Way, and as far as I could tell (peering over the front edge of the roller) They Had No Business Being There. Part of the responsibility must lie in your failure to integrate faster than I code, and part must lie in your failure to define what a "palletably small" chunk is, though I am willing to shoulder the lions share of the "blame", if there must be "blame" for you to Get Past This. My FS changes, in particular, built on a number of previous patches which were not integrated for philosophical reasons (I understand that you, David, and Garrett, at the time, discounted the value of SMP, given your expectation of increased UP locking overhead, and did not want to include my single entry/exit patches -- which WERE submitted seperately -- because of that, even though SMP locking state was not their sole utility: you could not see past it). This bloated the FS patches on each change, since they needed to carry with them the foundation blocks upon which they were built (since those foundations remained non-existant in FreeBSD), and which you had previously rejected those blocks, out of context, on the basis of their internal merits, rather than on the merits of what else could be built atop them. I finally submitted my patches in accordance with your rules 2 & 3 above *over* a year ago (end of May, 1995). It was far too late for rule 1 at that time: I had intimate need of my foundations, and they were impossible to seperate using the tools available by the time I had built a wall you liked on stones you didn't. Of what value is a concrete pylon in the middle of the San Francisco Bay, without other concrete pylons, and the steel and cables with which they will be eventually linked? I also understand your academic dislike for goto's, which were used in the *prototype* sysinit code rewrite I provided -- *as a prototype, not for integration*. You are not without blame for judging the average expected quality of my production code based on a prototype, which was, in fact, integrated over my objections. Or for the act of the integration itself. The result was, again, partially my fault, as I responded to an argument about "goto's", rather than pointing out that you had missed the boat. We devolved into a discussion about how to code assembly language without branches, and whether it was evil for a compiler to generate branch instructions, as I recall. To a large extent, you wish to serialize the process to keep it manageable. I wish to increase the concurrency of the process so that my foundations will exist when I go to raise walls. The reason I give out the foundation code *at all* stems from my desire to build *walls*, not *foundations*. That you do not integrate my multiple cement trucks full of foundation by the time I want to bolt on a sill plate is a *procedural* problem, not a problem with me wanting to bolt things, or the inherently "evil" nature of bolting things, or the nature of sill plates, or a comment on acceptable qualities of cement trucks. The same foundation stone can be used to build the basis for an abbatoire or a cathedral. Try to see the cathedral. I am willing to meet you half way, Poul: I am willing to recode on the order of *two years* work in "palletable chunks" if you will define what a "palletable chunk", in fact, is... though this will be a waste of my time, in that the eventual result will be that you get nearly identical code as an end result, as I "do the Limbo" in order to fly in under your "filtering radar". I am willing to engage in this, to my view, gratutious additional complexity, in order to demonstrate my willingness and desire to work with you. I am willing to wait for the Lite2 integration to be complete -- in fact, am willing to help Jeffrey Hsu debug the integration instead of pursuing my own (certainly, more valuable to *me*) research before submitting patches -- though I believe that the Lite2 code release has already provided you with sufficient time as a "submission" to have done the integration yourself, as keeper of the keys to the tree. This gratuitious serialization of what should be a trivial task (would be, if the original Lite code were properly vendor-branched) is a small proce to pay if I can finally get you to LISTEN. I would like to have some assurances that you will judge my submissions in the spirit they are intended -- as parts of a larger whole -- instead of judging them on their potentially small merits that result from them being broken up, as you ask above. Hopefully the intent of breaking them up is not so you can reject them on a case-by-case basis to destroy my ability to pursue the whole. You need to see the extrinsic, as well as the intrinsic, value they represent. Is there not some accord that may be reached? Do you truly believe that there is nothing of value I have to offer? Regards, 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?199606230026.RAA23261>