:> The API is intended for the stage-2 commit. The stage-1 commit :> is intended to do all the 'hard stuff' in as straightforward :> a manner as possible. The sysctl / option you talk about here :> existed in my patch set 2 and a half weeks ago. : :The API and getting it right is more important than the "hard stuff". :Its not as fun, but the API will outlive the code (consider the next :arch, and the next). It may take more of your time due to discussion :and feedback to get the API in place, but that's part of the cost of :collaboration. :... :> I really wish you people would at least read the patch and commit :> message before you comment on it. : :I didn't have to read the patch to know that there were concerns and :on-going discussion about the API. In this instance, the issues are :not large and can be remedied quickly - all the more reason for the :discussion to take place before the commit.
Again, bullshit. You should have read the patch. How can you possibly justify a lecture on what I should and should not be doing when you don't even read to bother the material under discussion? :I didn't have to read the patch to know that you didn't seem to care :about getting the API "right" before commiting the code. The API Again, complete and utter bullshit. You actually believe that because I want to commit this stuff in multiple stages and decided that the API change would be in stage 2, that this somehow magically means that "I don't seem to care"? How the hell did you come to that conclusion? Did you even bother to read the commit message? I'll tell you why I want to commit the stuff in multple stages... BECAUSE THAT ALLOWS THE CORE OF THE CODE TO BE TESTED WHILE THE REMAINING STUFF CAN BE DISCUSSED AND/OR WORKED ON. That's why. I am not going to spend months integrating change after change into a patchset, having to retest the whole mess every time, and then only after months commit the final result. That is not how I work and I strongly oppose that kind of methodology. I prefer to work in smaller chunks and yet here you are trying to justify your nonsense by making further attacks on my methodologies and code that are completely absurd and completely unsupported by any evidence whatsoever. This is complete and utter nonsense. You seem to believe you know a lot about my motives without reading one goddamn line of code. Because you know what? The commit message laid this all out in very clear terms. :I didn't have to read the patch to know that you would only remove your :commit if someone could point to specific defects in the "hard part" of :your submission. The "hard part", how it works, and whether it contained :any bugs or not was not the real issue. This is why you and John were :talking right past each other. Excuse me, but I think whether something contains bugs or not is a more serious issue then which source file the code winds up being in. And, again, you seem to be making ridiculous assumptions that are simply not true. Change the API? I am doing no such thing. I am expanding one portion of the existing API. The procedural interface has not changed. The procedure names have not changed. The location of the procedures change, and the capabilities of the procedures have changed, and certain restrictive assumptions regarding hard interrupt disablement have been changed. But you, and others, do not appear to be willing to face up to the code or its straightforward intent. Intead you are reading all sorts of garbage into its meaning, WITHOUT EVEN BOTHERING TO READ IT. It is unbelievable to me that a professional such as yourself would stoop to such tactics without backing it up with one shred of evidence and not even having bothered to read the code in question. And instead of standing up and apologizing for that, you instead feel that you have to start making wild accusations without one single hard reference to ANYTHING I have done. :.. :you can colloborate and coordinate with others in this project. The only :issue is how that colloboration takes place, and the *process* for getting :things done. If the process makes it twice as hard for us to get things :done, then it's broken. In that case, *attack the process*, not the person. :The process can and will change but only if we set aside "personal :indignity" (why should I have to put up with this crap!?!?) and attack :our problems and goals as engineers. Hey, I'm the one being attacked here. This whole mess started with people attacking me. If people had let well enough alone.. if people had simply read the goddamn patch rather then attack its intent (if you even know what it's intent is since so far you are batting 0 on that front), then we would not be in this situation. Instead it's attacked because it is perceived as 'Matt tromping all over John's stuff'. Except there is no 'stuff' to tromp over. Not a single person has shown how my stuff tromps over anything, not John, not you. So why the fuck do you feel justified to attack this commit? There is no tromping going on except in the minds of a few people who believe that John should be consulted about every last thing that goes into the tree, and they don't care if John takes three fucking weeks to respond. I don't understand why you and others believe that this patch is such a huge deal. It just isn't. It does not make any major changes to the API. It just moves things around and gives the critical*() code a few more features that allows architectures to optimize them a bit better, uses the new flexibility to implement a better backend for I386, and fixes a couple of nasty bugs to boot. It's important to me but I don't see how it could possibly have any adverse effect on the project and, frankly, I don't see why anyone, especially John, would be opposed to it (I don't even think he bothered to read the patch). -Matt Matthew Dillon <[EMAIL PROTECTED]> :Sometimes the flare-ups in FreeBSD remind me of the middle-east. Each :side accuses the other side of "starting it", or "having the blame". In :reality, both sides were jerks, own portions of the blame, and have :concentrated on continuing the conflagration rather than mitigating it. :I hope we have a better perspective on reality. : :-- :Justin : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message