On Sun, Feb 1, 2015 at 8:28 PM, Jean-Christian de Rivaz <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?
> 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.
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.
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.
/Andreas
------------------------------------------------------------------------------
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
