Tim Wescott wrote: > I suppose one is just supposed to know No, certainly not.
In my opinion, what is supposed to happen is that my (libusb maintainer) constructive and quite detailed review of code by a student who had not contributed to OpenOCD and seemingly not used libusb-1.0 before which added support for libusb-1.0 into OpenOCD would be respected by other maintainers in the OpenOCD project, rather than ignored or overlooked, as was the case when quite unfinished code was included into the repository, causing predicted problems such as the one you faced. Meanwhile I've been punished for pointing out issues in other instances, because maybe it is important to make an example or whatever, rather than focus on the fact that we are supposed to make the code as good as is at all possible together. Code quality isn't very highly regarded, not here and not in many other projects. It's unfortunate, because that would allow software in general to work a lot better. Anyone who pretends to care the least about software quality could take a look at this brief document from IBM, which has lots of good advice in it: https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/11-proven-practices-for-peer-review-pdf.pdf The Gerrit collaborative review tool used by OpenOCD and many others seems to be about on par with the product designed by the document author, except that it integrates with Git instead of ClearCase. :) //Peter ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
