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

Reply via email to