On Sat, 2009-05-02 at 01:01 -0500, Dick Hollenbeck wrote: > > Dick, > > > > Once again, "it's not you, it's me." Blah, blah, blah.... :) > > > > English please. No idea what the above sentence is saying.
It meant "do not take this personally, it's my opinion." The "blah blah blah" was because I figured this could be taken for granted. Guess not. > > On Fri, 2009-05-01 at 20:02 -0500, Dick Hollenbeck wrote: > > > >> This patch is large and: > >> > > > > ... should have been split into pieces. > > > > Take it or leave it. With your current attitude, I think it should be left, but I hope that you are speaking out of emotion. I would hate to see you go. > > > >> ** allows the ft2232 cable to be detached and reattached without having > >> to restart openocd. > >> > > > > Patch #1. Could this be made more general purpose so that it can be > > used by other USB devices? I would expect the J-Link driver could stand > > to benefit from similar support, but I could not find these changes > > because of all the others. > > > > > >> ** supports the high speed ftdi part (not tested) > >> > > > > Patch #2. You appear to have dropped the additional work that I did: > > > > > > https://lists.berlios.de/pipermail/openocd-development/2009-April/005479.html > > > > Where was this work? It was not in the repository that I could see. I > did not drop it, the maintainers dropped it. By the same argument, the maintainers dropped the first patch, and you found that on the list easily enough. Nevertheless, you ignored my central point: these changes should have been submitted separately. Do you disagree with that assertion? > Add the 3 > > #ifdef BUILD_FTD2XX_HIGHSPEED lines. > > and quit whining. Seriously? This is your attitude? How do you possibly think this is going to help you? It's _your_ patch, _not_ mine. > > This functionality looks impossible to extricate it from your patch. I > > have to admit that I am tempted to apply my patch first. The autotools > > work is required for this portion of the patch to build correctly on all > > platforms and with older versions of the FTD2xx libs. Moreover, the > > current mechanism for supporting RCLK is guaranteed to be wrong for some > > users without the explict configuration option. > > > > Can I commit my version first? I would think it should be relatively > > easy to work out any resulting collisions in the patch. > > > > > >> ** supports the reduced clock tms_seq table. > >> > > > > Patch #3. Not sure of the correctness here. Definitely should be > > separated for this reason alone. > > > > > >> ** modifies the reduce tms_seq table so that is worked with ARM9 and > >> Olimnex and establishes > >> a transition specific comment/documentation format for the reduced > >> clock table, in jtag.c > >> > > > > Patch #4. Ditto. > > > > > >> ** provides a reference implementation for any other drivers wishing to > >> add reduced clock support. > >> > > > > Patch #5. Ditto. > > > > [snip] > > > >> Let me know if there are any problems. > >> > > > > Patch #6: unrelated whitespace or style changes. Patches of this size > > should not have such cruft in them. > > > > We have an uncrustify.cfg file that infers a certain style. That was > accepted into the project months ago. By inference I could have run the > entire source file through uncrustify and I suppose you would have > whined even more. If you could have claimed that, you could at least have shut me up. As it is, I am not sure what your point was; you clearly missed mine. > I don't really give a shit what Linux kernel developers do. This is very undiplomatic. [snip] > It looks like I will have to fork the project. This is un-sufferable. > I spend a week and get this. Stuff it. Get what? An opinion? I did not deny your patch; I told you what I thought was wrong with it. You _asked_ for it. And you want to fork because I told you what I thought? It might be a good lesson for you, but I do not want you to fork. > I have never seen a project that needs to be forked as badly as this > one. You sit around and nit pick about about which dinner glasses to > pour the water into. Somebody shows up with a firetruck wanting to fill > the swimming pool and you can't handle it. > > This firetruck ain't waiting. Okay, Mr. Firetruck. Put up or shut up. What is so wrong with this community that it needs to be forked? Give us your manifesto. The soapbox is ready for you to shout it out to the masses. I will then try to address each issue that you have in turn. I have been where you are standing, and I am sure that I can withstand any flame you bring at me or this community. That goes for anyone else that is thinking the same thoughts. Vent it. It will feel good, and maybe we can move forward. Forks should be the last resort of the exiled or oppressed. You are not the former, and you need to make a solid case for the later. > BTW, the reason this patch was submitted as one is that it cannot be > separated. The system won't work with the reduced tms_seq clocks. When > does trust enter into this? Yes, it could be separated. I could do it myself, but I have my own list of tasks. My response was based on community standards with which you apparently do not agree. That is fine. I was not imposing them, rather providing my opinion. A strong opinion to be sure, so what? Again, I did not deny the patch; I deferring it to others guidance, because it touches key elements of the system. I am trusting other maintainers that have more experience to judge its correctness, because it is bigger than I can get my head around. They can chose to ignore or accept my opinion about it. Look, I would be happy to commit your patch, but I do not want to deal with fallout if there turn out to be bugs in it that I had missed. Someone else can take that responsibility; remember, I am new here. I am still learning the ropes, but I know good patches. I think yours needed work, simple as that. You have to trust me: it's not personal. I assumed that you would not mind some constructive criticism. Where does patience enter into this? Patiently Yours, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
