Le 02. 02. 15 00:27, Andreas Fritiofson a écrit : > > > On Sun, Feb 1, 2015 at 8:28 PM, Jean-Christian de Rivaz <j...@eclis.ch > <mailto:j...@eclis.ch>> wrote: > > Le 31. 01. 15 09:43, Paul Fertser a écrit : > > 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. > > > You're probably right that people not otherwise involved with OpenOCD > will not contribute quality review. And that's what's lacking. I think > the best suited people to review changes are those that contribute > other changes. If you go through the trouble of getting familiar with > the code base and care enough to push a change, why not go the extra > step of looking through the other pending changes and give quality > feedback to those that you find interesting? In in your own > interest... Why do so few contributors actually do that? >
Maybe because this not how most Open Source projects work. And, speaking for myself, I didn't understand this expected work flow before your message. It is not described in the "Patch Guidelines" descriptions. Only the last line of the page explain technically how to review, but not that every contributors is expected to review patches of others. As this is a unusual work flow, I suggest to describes it very clearly visible on the top of the "OpenOCD Developer's Guide". Still, getting review do not make a patch merged automatically. > > 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. > > > True, HACKING needs a lot of work in this area, I can see how it can > be confusing to a new contributor. We should make it clear that the > people doing review and the people contributing changes are the same > people. There is no-one else. There is no "review team" waiting > eagerly for the next patch to drop in. If contributors don't review > each other's changes, who will? There are a handful of "maintainers" > but basically the only thing that separates us from others is that we > can do the final submission to the main repo, it doesn't mean we are > the only ones that should do review. There's simply not enough time > for that. I share your analysis of the actual situation. Technically only maintainers can merge patches. This is an unavoidable fact. So, from a contributor point of view, it's important to know how to contact the maintainers and what there expect to accept to merge a patch. Getting review is required, ok, but how much review is enough for example ? > 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. > > > Before we introduced Gerrit we accepted patches sent to the mailing > list. Maintainers with commit rights pushed the patches directly to > the main repo. Patches were forgotten then too. I guess the difference > lies in the expectation of the contributor as to what's going to > happen after posting/pushing a change. > > If you send a patch to a mailing list you expect someone to reply. If > you hear nothing, you probably think that no-one noticed it or > bothered to look at it. If you care enough about your work, you'd ask > the list to take a look. If on the other hand you git push your change > to Gerrit, it's automatically accepted, build tested and "in the > system". You don't expect a human response, so you don't question a > lack of response. But after it's in Gerrit and approved by Jenkins, > it's the same procedure as the mailing list case. A human must take > interest in it, review it, make sure it's good enough and finally prod > someone with sufficient rights to approve and submit it. It's just as > easily forgotten or ignored. > Agree. As a newbie here I found the part "prod someone with sufficient rights" to be the most difficult step on the actual OpenOCD project work flow. > 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. > > > Gerrit is absolutely not for discussing new features or architecture. > It sucks at that. It doesn't even have a basic system so you can reply > to others comments. Please use the mailing list for these kinds of > conversations and use Gerrit only for reviewing and commenting > patches. What Gerrit+Jenkins does for the project is that it makes > sure that you can always pull master at any time and be sure it will > build and most likely work well. That's worth any inconvenience it brings. I could be wrong, but I used the "reply" button (at the right of the first gray bar) on the Gerrit interface to reply to comments. Seem to work as expected. Or I maybe misunderstand your point. I observe that the more experienced contributors used the Gerrit comments interface to talk about architecture used by my patches. So it's a bit confusing. 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
