Date: Tue, 21 Jan 1997 21:41:53 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@freebsd.org, terry@lambert.org Subject: Re: Terry Message-ID: <l03010d03af0b2240fcc6@[208.2.87.3]> In-Reply-To: <19361.853887384@time.cdrom.com> References: Your message of "Tue, 21 Jan 1997 13:37:00 MST." <199701212037.NAA19913@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> As a specific example: The failure to even define what an acceptable >> build system should look like so that there is some reasonable >> assurance of acceptance of the work, after the effort is to be >> expended on spec., has blocked out at least two "warm bodies". > >Now hear this: Nobody, and I repeat, nobody is going to define an >"acceptable build system" for you or anyone else. > "Acceptable" in >this particular context means "works for all our tools and solves >problems which are unsolved by the current build system" (or there >wouldn't be much point in doing the work), THAT sounds like a definition to me! However, I would wish to modify it somewhat. In particular, in order to achieve some of the goals, it may be necessary to "break" some things. I contend that some of them need to be "broken" simply because they are not consistent with the current state of the art. I do however agree that we cannot break the functionality. I go one step further and contend that we not only have to replace changed functionality, but have to do so in a manner which provides a continuous sequence of working intermediate steps. > and if I'm going to do all >the work of designing a new framework, verifying that it works for all >the conceivable build situations and is architecturally sound, then >I'm bloody going to go the rest of the way and implement it, no doubt >to find other problems with my logic along the way - nothing else >makes much sense. The definition *IS* a very large part of the work >and expecting someone to do this for you is just ludicrous. Now, please consider the above paragraph from MY perspective. I agree that 1) the task is large and that 2) the definition of details is most of the work. But that is exactly what I have told I must do before I get any feedback. "show us the code that does it and we will see if we like it" However, I am unwilling to put in all of that effort only to have someone step in at the last moment and veto the entire effort simply because I stepped on their precious toes. >That's why you and Richard haven't gotten anywhere with the new build >system. Richard claims he needs carte-blanche with the build tree to >do a number of unspecified and yet-to-be-defined things to it, none of >which he's been willing to even put out for review. WRONG! I want agreement that we will first explicitly agree to a design methodology. That methodology has absolutely no "code" in its definition. Following the methodology, we will next determine (propose, discuss, AND REVIEW) the design goals. In particular, we will state the criteria which must be met in order to have a design declared "acceptable". At this point I do wish "carte-blanche" in developing a design to meet the stated criteria. That is not to say that such design will be done without even more discussion. However, it does preclude someone comming in later and exercising a veto simply because the design does not meet some goal that was not previously specified. Without knowing exactly HOW the design will meet the goals, I do know from previous experience that certain things will need to be modified. This modification will have to be done in a "side-stepping" manner in order to meet the "incremental continuity" constraint that I include in the design requirements. By the very nature of these changes, they will not, in themselves, create any improvement. In fact, there may be temporary digressions. However, they will be establishing the base upon which the final design is built. Again, I would EXPECT that the details of the individual steps would be REVIEWED, tested, and demonstrated in order to help assure that they do not "break" things. However, that review is not permitted to question whether they, standing alone, improve things. That is replaced by only the question of whether or not they help move us along a path to the proviously established destination. > You want a spec >to follow or some sort of "happy meal" in a convenient box, but who's >going to do the work of providing you with all of that? And having >done all that work, why wouldn't they simply follow through with it >themselves rather that trying to wet-nurse another engineer through >their design? I think that you and I are talking at different levels. By a "spec", I want performance requirements. In particular what existing methodology is sacred? For example, do I HAVE to keep "/usr/obj" or am I allowed to substitute some other mechanism in the final implementation as long as that mechanism allows the use of a scratch disk for the intermediates. This is a long way from the detail specification which I would produce in the course of the design and implementation. >Neither set of demands is reasonable or even constitutes good >engineering, and were I to agitate for similar sweeping changes to the >build system myself then you can bet that *I* would also encounter >significant and justifiable resistance from within the core team until >I'd truly explained to their satisfaction how I wasn't going to break >the entire world or replace it with something far worse. The build >system is one of those special examples of something which effects >practically *everyone*, and if you're prepared to contemplate such >changes lightly (or expect the core team to do the same) then you're >not thinking very clearly, nor have you even shown yourself willing to >explain it to *anyone*'s satisfaction. How could this do anything but >fail? I do not take it lightly. As for "explaining it", I have REPEATEDLY been told that the ONLY acceptable "explanation" is a FULLY working implementation. These people do not seem to grasp conceptual designs. Instead they are stuck at the "nuts and bolts" level. I fear that this effort is doomed simply because everyone wants to withold judgment until the project is virtually finished and then veto the whole thing because there is some minor inconvience to them individually. They are unwilling to give up any of their own convienence for the common good. And I have no desire to attempt such a project in the hopes that it will "appease the gods". I wrote my operating systems 30 and 25 years ago. I don't have to prove to myself that I can do it again. If I am going to do something "for fun", I want the assurance that someone will not shoot it down just to prove that they have the power to do so. That is the purpose of the "contract". If the goods meet specification, you are required to accept them and pay for them. In this case, the "pay" is their incorporation in the system. You are not allowed to change the specification at the last minute and refuse the goods.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03010d03af0b2240fcc6>