Date: Thu, 7 Mar 2002 12:03:22 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.ORG>, Julian Elischer <julian@elischer.org> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200203072003.g27K3M368992@apollo.backplane.com> References: <200203071923.g27JN6I60361@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:You came to the conclusion that only *your decision* on what was
:an appropriate proceedure was the one that mattered. That's not
:the way this project works. You can't act unilaterally. When people
:ask you to hold off (and they even asked politely!) so discussion
:can take place, that is not the time to commit.
I did no such thing. I came to the conclusion because not a
single goddamn person bothered to read the patch and instead
the only argument I got was "wait for John" and John's only
argument is "I don't like the idea of optimizing this routine
right now" as if he would be the only one responsible for
dealing with the consequences.
I'm sorry, but simply not liking the idea of someone else doing a
particular optimization now verses later is not a good enough reason
to require that 40+ hours worth of work be thrown away when that
other person has stated, repeatedly, that he will support said code.
So far not one person, not even you, has been able to explain why
the patch should not go in. John's only excuse is that he doesn't
like the idea of optimizing it now. John has stated on several
occassions that he believes I am breaking future work (like preemption).
I have responded every time by asking him to clarify exactly what he
thought would be broken. He has consistently refused to clarify his
statement. I have read his tiny little 10-page SMP document and there
is absolutely nothing in that document which is at odds with my patch.
Not one thing.
I am angry because you and a number of others are not willing to take
the work at face value and instead insist on making ridiculous extremist
assumption into it and then using that opinion to justify not allowing
the patch to go in.
I have said, REPEATEDLY, but you can't seem to understand, that I am
totally open to making adjustments to the code. I am not willing to
throw it away, but I am willing to make adjustments to the code. I
don't see why the patch should be held up. But you know something?
You and others don't seem to be interested in having a conversation
about possible improvements. You seem to be out for blood, to prevent
the patch from going in at all costs no matter how good it is, without
even having bothered to read or understand it, and that makes me
unbelievably angry,
I don't see how you can possibly tell me that I am not being a team
player when I am being told to throw the code away completely. I
think it's John who is not being the team player here, and others,
who seem to believe that me throwing the code away is the correct
solution to their ills.
:> 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.
:
:One week of discussion will not prevent the code from being tested.
Coming on THREE weeks now. Three weeks of my time wasted arguing
with people who don't even bother to take the time to understand what
I am trying to accomplish, who seem to regard a relatively
straightforward patch as somehow being an attack on John's leadership
when that could not be farther from the truth, who seem inclined to
do nothing but bash me personally and supply opinions without one shred
of evidence to back them up.
I can't fight your opinion of me, but you can't expect me to listen
to you if you can't justify it. You have already shown very clearly
that you aren't even interested in looking at the code, that you
don't care what it does, but you are against it anyway. You response
is to ignore the points I have brought up and then start bashing me
personally.
:> 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.
:
:I've counted weeks so far and those weeks weren't even necessary. Now
:your expecting months and years of delay? Please.
Gee, lets see... why don't YOU ask JOHN how long he intends to wait
before he allows this sort of optimization to be made? Eh? Please.
:
:> That is not how I work and I strongly oppose that kind of methodology.
:
:I think you've made that clear already. The question is whether you
:are willing to compromise so you can be part of a team or not. That
:means, for all of us, that we will not necessarily be able to work in
:the way we would personally want, all of the time. That's what happens
:in a group environment. That's life.
This is not about being part of a team. You don't have to be forced
into using someone else's methodology to be part of a team. Being
part of a team means respecting other people's metholodogies and
it means compromising. There has been no compromising here... John
has made it clear that he doesn't want any work whatsoever to be done
on the critical*() code. I can't even get THE FIRST GODDAMN STAGE
OF MY PATCH IN.
This IS about team work, but you are barking up the wrong tree if you
think I'm the one who's not being a team player here. There is plenty
of room for discussion. But discussion != Veto. It isn't a discussion
when all you try to do is prevent code from being committed to the
tree. I have said REPEATEDLY that I am willing to adjust the code
based on a discussion. But I feel, strongly, that the Stage-1 code
is ready to go in now so a widier audience can test it. I do not
believe it is appropriate to simply veto it.
I HAVE NEVER SAID THAT THE CODE COULD NOT BE CHANGED. Hello? Are
you even listening to what I am saying? I do not feel that weeks of
discussion are necessary before the first commit, but that does not
imply in any way shape or form that the first commit somehow sets
things in stone.
:> 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 not an attack on any such thing. This is about *process*. You
:want to commit in small chucks? Great! You want to get this stuff into
:the tree quickly? Great! You want to make the code so it can be dynamically
:configured for testability? Great! You don't want to discuss API changes
:that have affects on other ports, and other subsystems prior to committing
:them? That's unacceptable when people are asking you to explain them first,
:regardless of how well thought out or implemented they are. This is not a
:race to commit. This is about developing a well designed system without
:killing each other in the process.
Say what? Who said anything about me not wanting to discuss API changes?
That's all I've been TRYING to do for the last three fucking weeks!
Are you discussing API changes? No, you are basically just bashing me.
That's all that you people have been doing for three fucking weeks.
Not a single one of you has discussed WORD ONE about the API.
Instead of harraunging on me about not discussing the API, maybe
you should consider discussing the API. I haven't even changed the
goddamn API yet! The stage-1 patch isn't about the API, it's
about proving that we can leave interrupts enabled, and it's about
fixing bugs.
:For this kind of change, the commit message should have been the last,
:not the first "public forum" to have expressed these ideas.
:
:>: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.
:
:Did I say anything about source files? This is about discussion prior
:to commit. Nothing more.
So far there has been no discussion. Not a single person, most
especially john, has attempted to initiate any constructive discussion
about the API.
:> 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.
:
:How is expanding an API not a change to that API? Why is it that when
:other developers express a need to discuss these changes prior to them
:being committed, their concerns don't matter to you? Are you the only
:person in the project that can't keep changes in your local tree for
:a few days while you present your ideas?
Do you even know the change I am making? The other developers so far
don't seem to be interested in talking about the actual CHANGE I made
to the API. The only discussion about the API changes were made by
me and BDE. Everyone else seems intent on bashing me and bashing
the patch but do not seem to be interested in having a discussion
about what the patch accomplishes.
:> 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.
:
:I have done no such thing. The facts are very simple:
:
:Matt: I'm going to commit this code to the tree
:Others: We should discuss the rammifications first.
:Matt: We can discuss it after its in.
:Others: No, we need to discuss it first.
:Matt: Commit
:Others: Back it out until we discuss it.
:Matt: !@#$%^$@#. Every time I try to do something its blocked....
:
:The content of the changes simply don't matter.
You obviously didn't go back far enough. These are the facts:
Matt: I'm having a go at fixing critical_enter (Matt discusses
what he would like to do).
Bruce: Say, I did something very similar to that.
Matt: Really? Why didn't you commit it? Could I have a copy
of what you did?
Bruce: I hacked a bunch of the issues and it is mixed in with
other things. Here's a diff of my sys tree.
Matt: Wow! Great stuff.
(Matt goes off into a corner and does his stuff, using
BDE's code).
Matt: Ok guys, I think I have something that works, here try
this.
(two days pass, a few people respond positively)
Matt: Ok, I am going to commit this.
Others: wait a week for John.
Matt: huh? I don't think this interferes with anything john is
doing.
Others: wait a week for John.
And it went forward from there. My ucred changes were already on hold,
and now I was faced with waiting a week for a John. Well, after all
of that I finally got tired of waiting. I said, very clearly, that
(A) I intended to commit it. That (B) I had no problem discussing
issues with the (unresponsive apparently on vacation) John after the
commit
And from there it blew up into the mess you see today. So, you see,
I didn't "just commit it out of nowhere". I waited what I believed
to be a reasonable period of time. I have two other stages waiting
in the wings, and, yes, I don't think it's appropriate for one person
to be able to arbitrarily hold up dozens of hours of work for an
arbitrary period of time, especially when that person (me) is perfectly
willing to make changes to the code in later commits.
Now who is being unreasonable? Why do you believe that it is absolutely
necessary that I be prevented from committing the work?
:> 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.
:
:The evidence is in the lists, not the code.
And so is mine.
:> Hey, I'm the one being attacked here.
:
:No. There was nothing personal in Robert Watson's request for you to
:wait. He would have said it to anyone in the same position. I don't
:know why you took it as an attack. Robert was just trying to place some
:proceedure (just as he did at the devcon) on what has been a very
:chaotic process.
If someone asked me to wait a day, or even two, it would not be
a problem. But if someone asks me to sit on my heals for a week, or
two, or THREE, without any direct justification, then, yes, I consider
it to be an inappropriate request.
:...
:It is only a huge deal because it was made into a huge deal. If the
:change had been discussed prior to being pushed into the tree, this
:would never have happened. I don't think that John, or anyone else, is
:opposed to the change going in once some small issues are discussed first.
:Just get over this "I've been abused" bit already and discuss the changes!
:We all want to move on and I'd rather see us moving on with your changes
:than without.
:
:--
:Justin
It's only a huge deal here because you people have turned it into
one.
This patch has no adverse effect on anything that ANYONE is doing,
including John, and yet you and John and a few others seem unwilling
to even consider it on the grounds that it somehow interferes with
John's perfect plan for the futuer of SMPng. I do not believe it
interferes with his plans at all and I have repeatedly asked you and
others to supply hard facts as to why you believe it does. Not a
single person has been able to supply a single fact showing how it
interferes so significantly with any other work that it must not go
in at any cost, and that really pisses the hell out of me.
I will repeat: This is a damn good patch. I want to see it go in.
I am willing to discuss the API changes. I do not believe it is
appropriate to simply veto all the hard work I have done here without
supplying a single hard reason as to why, and that is what you people
are doing.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203072003.g27K3M368992>