> Dick, > > Once again, "it's not you, it's me." Blah, blah, blah.... :) >
English please. No idea what the above sentence is saying. > 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. > >> ** 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. Add the 3 #ifdef BUILD_FTD2XX_HIGHSPEED lines. and quit whining. > 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. I don't really give a shit what Linux kernel developers do. > My rules of thumb (again, based on the Linux kernel community) says that > style changes are acceptable on lines already being changed, so long as > they improve the quality of the patch itself and move toward a community > ratified style. > > Patches that mix both functional and style changes should be avoided > entirely, but that is only half the story. I expect contributors to > work on one task per patch, submitted either one at a time or as a > series of patches. I expect that because it is what I have come to be > expected of me; it seems to be the best practice. > > Of course, I cannot expect to hold others to that standard today, as > that would be changing the rules retroactively and without consensus. > Nevertheless, I feel a little uncomfortable simply committing the patch > without it being split, and I will not presume to ask for you to do so. > As it stands, the scope of its change has the potential to impact users > of all OpenOCD interfaces; I must defer to other maintainers opinions. > > > In the future, I hope that I can convince the community to produce > patches that reach these standards of quality. I do not expect everyone > to agree with my perspective, nor would I expect a transformation to > happen overnight. Moreover, I would not want these "requirements" to > dissuade potential contributors from sending in their patches, as the > clean-up work can be excellent for new coders that want to learn how to > improve their coding style (and some people may never change). > > As always, I am also open to criticism or comments. If anything, send > your concerns privately; I am not try to bully the community into doing > anything that it does not already think it should be doing. This kind > of discipline is like dieting; very few people will do it willingly, but > the results are lean and fit after all of the effort. As I see it, > being a "maintainer" means keeping the community on its fitness regime; > I expect you to hate me until the results start to show. ;) > > Cheers, > Not really. It looks like I will have to fork the project. This is un-sufferable. I spend a week and get this. Stuff it. 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. 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? Good bye, Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
