Dick, Once again, "it's not you, it's me." Blah, blah, blah.... :)
On Fri, 2009-05-01 at 20:02 -0500, Dick Hollenbeck wrote: > This patch is large and: ... should have been split into pieces. > ** 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 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. 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, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
