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

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
was "something to be cleaned up later".  "If you have problems with
my API, I'll even help merge your changes into mine, but I need to
commit now."  "Lets discuss this after the commit."  This project is
not about a race to commit. [Perhaps my viewpoint here is a bit different
then some seeing as the CAM stuff was 1.5 years old by the time it was
committed to the tree.  I know all about painful merge conflicts.]

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.

Don't get me wrong, Matt.  I don't think you should be unduley held off
from committing either.  From my perspective of the discussion so far,
other than the delay for John to get back home from BSDcon, we could have
finished the discussion about the API and committed this stuff a week
ago if the focus wasn't on how you were personally wronged, or "John is
holding up the whole tree", or "my changes are correct, my changes are
correct".  All of the above may be true, but focusing on the particular
events instead of the *process to avoid them recurring in the future*
will only lead to more frustration and you wanting to work on -stable instead
of -current, etc.  You're a good engineer Matt.  You've shown before that
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.

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