Hello, On Mon, Feb 02, 2015 at 12:27:18AM +0100, Andreas Fritiofson wrote: > On Sun, Feb 1, 2015 at 8:28 PM, Jean-Christian de Rivaz <[1]j...@eclis.ch> > wrote: > I doubt that peoples that never contributed to OpenOCD are in good > position to review patches for it. I don't say that it a kind of fake > review, but I suspect that it will add nothing in term of quality. > > You're probably right that people not otherwise involved with OpenOCD will not > contribute quality review.
I have to admit I understand computers way better than I understand humans ("People are strange, when you're a stranger"), so take this with a grain of salt. I still think that it's beneficial to ask your fellow programmers to review your patches, even if they are not familiar with the codebase and can't provide quality review, and here's why: 1. Bad quality review won't hurt much, it's not like we're going to be overwhelmed with it any time soon, and they're easy to spot; at the same time chances are we'll get good quality reviews sometimes, and that'll help; 2. We all have brainfarts occassionally, and for plenty of this type of mistakes one doesn't need to be familiar with the codebase per se to spot it; 3. Rubber duck debugging [1] is a widely established method of improving one's work, I consider talking to your fellow programmers about the patches to be at least as efficient. Also, when talking face-to-face, people are likely to ask more questions, hence the author will have to put more thought into the work; 4. It's highly probable that if your coworker is doing embedded programming too, he or she might be using different hardware tools and/or using the software in a way that you normally do not, hence you expand your test coverage by asking them to review. This way I got a bugreport regarding my CMSIS-DAP patch and ULink ME incompatibility (and he is a windows user btw, so he had to self-build to try my work) and promptly fixed the issue; 5. By asking people to review patches you can help break mental barriers that prevent them from getting interested and contributing, as they get first-hand experience proving that participating is not really hard and can be joyful. Granted, the success rate here is not high, but even if it's, say, one in a hundred, it's still worth doing, as there're several thousands users who can potentially become contributors. [1] https://en.wikipedia.org/wiki/Rubber_duck_debugging -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel