Site Tools


Contributions can be in different form, you can report bugs or remarks help on documentation or any community actions.

First look at start page and then check these links about code contribution:

The project is using git version control and the gerrit code review system, we encourage you to learn a bit about using them, don't hesitate to ask for support at community, we are here to help.

Community tips and suggestions:


Contributors are expected to be able to explain why the contribution is necessary and appropriate, and to otherwise respond to feedback. Remember that the community represents lots of different needs and viewpoints and what looks obvious to you may not be to others (including the maintainer in the affected area); reviewers may also suggest different approaches to solving the problem. This is not done in a spirit of meanness even if some reviews sometimes sound harsh, but to try and achieve the best solution to a problem.

For large changes - adding a new feature, new APIs, etc. contributors are expected to stick around and maintain the contribution as issues may appear that were not evident early on. iotivity is a fairly complex stack of software with lots of possible interactions. Small bugfixes, documentation updates, etc. would not likely not carry the same expection of support, although of course contributing to an area may put you on the radar to be asked to review changes in the same area later!

Smaller is better

please make patches as small as possible, there are many benefits of doing this

  1. easier to review
  2. quicker to be merged
  3. lower chances of conflicts
  4. less work when your unmerged patch goes out of date due to other merges
  5. easier to revert on bisect

It is understood that this is a bit of a burden: if you have more than can be expressed in a single small patch, it means juggling several patches and keeping track of the flow as they merge, the gerrit workflow for multiple related patches is not like some projects where you split into 27 related but independent patches and send them all at once to an email list for review. Each system has different characteristics.

Earlier is better

Related to the previous, it is not wise to gather up a huge change and submit it all at once with the note “we need this merged because a product we are releasing in a month depends on it”. If you need a change merged, get it started as early as possible to get people used to the idea, sending small pieces to edge towards the goal so you don't risk having the big change rejected. If you've gotten most of what you need merged, and something doesn't make it in, the patches you have to keep track of locally to add to “official IoTivity” will be much smaller and more manageable.

Commit messages

Adding a gerrit field can help reviewers find important context. For example, the Bug: field lets the reviewer in the web interface jump to the bug tracker from gerrit with a single click from the browser:

 Change-Id: deadbeefbadbedbadc0ffeabadc0de
 Signed-off-by: ...

The first line of the commit message is the “subject” line, you can prefix it with some context “[IOT-0]” or the domain your change applies to, like:

 tizen: Enable Z to support X
 [IOT-0]: Fix resource cleanup in class foo

Note that domain is more helpful when looking at history, and BugId can be parsed from Bug: field if used. This technique got a little less useful with the latest infrastructure update of gerrit, a first-line length limit of 50 characters is now enforced. Short commit subjects are hard; if adding context identifiers makes it too hard, leave them off but supply the context somewhere else in the commit msg.

Other keywords that could be used are:

Suggested-by: ...
Credit-to: Name of person <that@who.proposed.this.first>
Thanks-to: Name of person <that@helped.somehow.on.this>
Reported-by: Name of person <that@reported.problem>
Bug-XYZ: $url (downstream projects)
Origin: $url (where patch is coming from)
Forwarded: $url


gerrit picking to destination branches

If you want to push a change in different branches, target one branch (ie: master) and then from gerrit click on “cherry-pick” button and select destination branch, this way we know the review has been done previously.

There is not fixed rule, but landing first in master is better, but fixes can land in x.y-rel branch first, but new features are not for release branches unless it is justified by a ticket.



If you need to reach reviewers you can add the topic that match best your change. we can use topic name the name of folder where files are changed. That way maintainers can see that patch by using filters like:

Or you can search per path, ie:

Also you can use platform name (“tizen”, “android” etc) or generic names like “build” or “mergeback” (as explained in 1.2-rel page).

You can find more reviewers using:

git log $file | grep 'Reviewed-by:' | sort | uniq -c | sort

Downstream patches

If the patch is coming from elsewhere, you can add Origin: Field, for more tips about upstream/downstream cooperation model check this presentation about Debian inspired flow for Tizen (p8 to 22):


Other projects use gerrit, there are a number of Internet posts on developing an effective workflow. While those may not exactly work for IoTivy and need some adaptation, these workflows will present some useful ideas. Here is one:

IoTivity has a way to run unit tests that differs from that one, just FWIW. On platforms other than Windows native, use

./ unit_tests

. On Windows native, do

run build

(running the tests is default there).

contribute.txt · Last modified: 2018/01/08 09:14 by rzr