Date: Tue, 21 Jan 1997 22:57:15 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Richard Wackerbarth <rkw@dataplex.net> Cc: hackers@freebsd.org, terry@lambert.org Subject: Re: Terry Message-ID: <9874.853916235@time.cdrom.com> In-Reply-To: Your message of "Tue, 21 Jan 1997 21:41:53 CST." <l03010d03af0b2240fcc6@[208.2.87.3]>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 No, you don't break anything. If you change some Makefile macro so that /usr/src/bin/cat no longer compiles, you also fix /usr/src/bin/cat or people will see how many times they can jump up and down on your head, and most deservedly so! :-) > 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. Right, so you already understand what it takes to keep people from standing on your head. Sounds like a promising start to me. > 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. You wouldn't be stepping on anyone's toes and no one in the core team feels particularly paternal towards the build system, in fact most core team members can fill you in chapter and verse about its various shortcomings. This still doesn't mean you can say "OK, I'm going to rampage through the source tree now" and not give anyone the slightest idea of what you're going to be up to somewhat in advance. See below. > WRONG! I want agreement that we will first explicitly agree to a design > methodology. That methodology has absolutely no "code" in its definition. So let's see your design methodology then. How can we agree to something we've never even seen? > 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. I have no problem with setting goals, reviewing them and coming to a common concensus about what we're willing to have done to the tree. If you can then work within those lines, your design will not be veto'd over some last minute contractual change. Mind you, you could very well prove to be a complete incompetent and your changes could all suck mightily, in which case we would have to reserve the right to reject what would only do the project harm, but if you actually do have the skills to pull this off (and I don't really want to hear arguments either way, I'm simply saying that we don't *know* for sure what you are yet) then that's great and I don't see any problem. We didn't jump on Justin once he was done with his reorg of the SCSI driver, or tell John Dyson after he was finished: "Uh, sorry, no - we changed our minds. Forget about the merged VM/buffer cache stuff." Ideas with genuine merit and a quality implementation are gladly accepted. Since we don't know you very well at all, it remains purely to be seen whether your ideas have either merit or quality before any idea of "carte blanch" can be extended. You simply haven't done anything which lets us know how to categorize you either way, and this is not the catholic chuch - unswerving faith is not our answer to the unknown. > Without knowing exactly HOW the design will meet the goals, I do know > 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 individu Fine, that's all fine - we don't expect you to build Rome in a day or spend your entire time sculpting elaborate and highly visible frescos. We simply would like to know whether you're a master builder or merely someone with pretentions to being one, and the only way we can know that is to see the quality of your work. > 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. Though it would still remain incumbent upon you to explain the long-term significance of a set of changes which confer no short term advantage and are purely infractructural. No one expects to review the build system in any kind of stand-alone context anyway since that's basically a useless exercise given the highly inter-related nature of the changes. > 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. And is superior to the existing mechansim. Change for change's sake or because it doesn't smell like Richard is clearly bad. Change for the sake of a real advantage (which you can cite if and when asked) is just fine. > 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. OK, perhaps I communicated this poorly then. Let's change this to "the ONLY acceptable explanation is a design document and the will to follow through with it using the ratified final version." I think that's more than reasonable. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9874.853916235>