Le 02. 02. 15 08:55, Paul Fertser a écrit :
> 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:
Sorry, I don't have fellow programmers. I work on 2 peoples company we
setup ourself. And I don't want to ask my associate to add what will
basically be a fake review. He is busy at others tasks that require
others skills.
> 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;
Maybe ( I am not so convinced ). Still review is not enough to have a
merge, the final goal.
> 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;
I don't understand this point. Did you have an example ?
> 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;
Sorry, I disagree on this. While this method is technically working when
you have a lot of competent peoples with massive free time, he is
totally inefficient from a productivity point of view for anything other
than very precisely debug a problem you fail to catch with.
>
> 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;
My coworker is buy at other tasks not related to embedded programming.
> 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.
>
As probably any OpenOCD contributors, I want to have patches merged if
there are good enough. It's sound logical to deal for that goal with the
existing OpenOCD community rather than making social engineering trying
to involve unrelated people that share no interest about OpenOCD.
Especially if it's only to only get a +1 on a table and that the merge
will no happen anyway. Sorry if it's a bit rogue to say that, but after
more than 2 months trying to understand how to extend SWD to sysfsgpio
it's the kind of feeling I actually have.
Jean-Christian
------------------------------------------------------------------------------
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
