:>    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
:>    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 

: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...

    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

    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

                                        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.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to