>: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?
Because it isn't relavent. Until you see that, you will continue to be frustrated. You will continue to get angry. You will continue to butt heads. You will continue to act unprofessionally on our lists. You will continue to piss people off. And most importantly, you will continue to lose the battles that you care about. Is your code in the tree right now? No. That above all else shows that your tactics are the wrong ones. >: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? 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'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. > 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. The only way it will get delayed that long is if you spend all of your time stomping up and down, writing in all caps, and tell the rest of us that we have to follow the proceedures you think are appropriate. That's not how colaboration works. You need to compromise and not get all pissed off if the process requires you to delay your commit for a bit. > 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. > 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 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. > 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. 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. > 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? > 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. > 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. > 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. > Instead it's attacked because it is perceived as 'Matt tromping all > over John's stuff'. That's not how I perceived this at all. John needs to be active in the discussion on changes so they are resolved quickly and don't hold you back. I have not said one thing about your changes not going in other than to say that they should be discussed first. If John doesn't want to have to merge with you, he'll have to get his patches into the tree just like anyone else. Regardless, you have to be willing to discuss and perhaps refine your changes prior to committing them. This is true for anyone on the project, not just you. > I don't understand why you and others believe that this patch is such > a huge deal. 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
