Hi Paul, First I want to thank you for your response. It really help me to understand how the OpenOCD project work.
Le 31. 01. 15 09:43, Paul Fertser a écrit : > On Sat, Jan 31, 2015 at 12:01:45AM +0100, Jean-Christian de Rivaz wrote: >> Le 29. 01. 15 11:28, Paul Fertser a ecrit : >>> IMHO, organisational issues, mostly. It would really help if the >>> contributors would be more persistent about their patches, and also if >>> they would actively try to find reviewers, e.g. among their coworkers. >>> >> I have 2 patches is this state. Should I "spam" the list to ask for >> reviewer ? > If you are just asking for review, it's not spamming. So yes, in case > the patches are not getting any feedback for too long, you can write > to the mailing list, you can complain on IRC, etc. You can also add > relevant people (those who contributed related code lately) via > Gerrit's CC feature. Ok. Good to know. (I prefer email for my case). I think that I carbon copy everyone that corresponded with me about my patches. >> Or should I use an other email address to add a fake >> reviewer ? > Fake reviewers do not help improve code quality. But real reviewers > often do. Of course. This part of my message was I bit extreme. > > Most of us have coworkers or friends or fellow students who work in > related field. So when you're sending a patch, why not ask them to > review it? It's not hard, and it's fun, and you have a chance to > discuss your code with them (and sometimes it helps a lot, see "rubber > duck debugging"). 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. >> Don't take me wrong, I have no emotion about this situation. I >> already have experienced this on others projects. I just try to >> figure out what action I could do the make the process flowing. > If you have any suggestions about how we can realistically improve the > experience for the contributors, we're open to the discussion, really, > we need more feedback on all the areas, both user experience, and > developer experience. > I can only speak about my experience. I found the "Patch Guidelines" very good up to the patch submission part. The explanation of the review process is only conceptual and leak the description of the expected actions options from the contributor to get his work merged. I missed the informations about the list of peoples that have the right to merge commits and are willing to accept to do it for the patches of newcomer like me. My experience with others opens source projects is that either there is a list of maintainers, or that (almost) any submission is actively discussed on the mailing list up to the point an agreement is reach. There is a few projects where submissions are quietly forget without so much informations to understand whats going on. OpenOCD use Gerrit. I make a few mistake before learning how it must be used. Probably that Gerrit help the project to formalize the patches submissions, but I get the (wrong ?) feeling that Gerrit don't help discussing the project architecture about new features. Regards, 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