Contributing Code to Tizen

1 Introduction

This document provides information about how to contribute code to Tizen, including the following:

  • Submit a patch to the Gerrit
  • Review a patch on the Gerrit
  • Submit a package to the build system
  • Review and accept a package on the build server (for release engineer only)

For more information about the whole work process, please refer to Tizen Development Working Mechanism.

2 Patch Submission and Review on the Gerrit

This section describes how to perform patch submission and review on the Gerrit.

2.1 Submitting a Patch to the Gerrit

This section describes how to submit a patch to the Gerrit.

To submit a patch to the Gerrit, perform the following procedure:

  1. Switch to the project directory and perform local development.

  2. Stage the revised content by executing the following command:

    $ git add <Revised_File>...
  3. Commit the revised content by executing the following command:

    $ git commit
  4. Push the patch to Gerrit by executing the following command:

    $ git push origin HEAD:refs/for/<remote_branch_name>

    Note: Valid values for <remote_branch_name> are as follows:

    • tizen_2.1: corresponds to Tizen 2.1 branch
    • tizen_2.2: corresponds to Tizen 2.2 branch
    • tizen: corresponds to Tizen 3.0 branch

For more information, refer to Gerrit Documentation.

2.2 Reviewing a Patch on the Gerrit

To review a patch in the Gerrit web GUI, publish the comments and vote for the patch, the patch will be merged or discarded depending on the voting results.

More specifically, a patch will be merged on the following conditions:

  • The patch got at least one "+2" score and no "-2" score in the Code Review category.
  • The patch got at least one "+1" score and no "-1" score in the Verified category.

Note: Voting "+2" requires proper privilege level. In addition, more than two "+1" serves as "+2".

When a patch meets all the criteria above, privileged users are allowed to click the Submit and Merge button to merge the patch into the Gerrit repository.

3 Package Submission and Review on the Build System

This section describes how to perform package submission by developers, and for release engineers, how to review and accept the changes on the build system side.

3.1 Submitting Package(s) to the Build System

This section includes the following:

  • Submitting a package
  • Submitting a group of packages

3.1.1 Submitting a Package

To submit a package to the build system, please execute the following command:

$ gbs submit [-c <Commit_ID>] -m "<Comments>"

During the submission, the GBS automatically creates an annotated tag in the format below:


If the code change has already been merged by the Gerrit, a merge request will be created and release engineers will be notifed to review.

Important Note: if the patch has not been merged in Gerrit, the backend services will abort the operations and send email to the patch owner, to notify that the patch needs to be re-submitted after it is merged.

3.1.2 Submitting a Group of Packages to the Build System

For multiple changed packages that have mutual dependencies, the submission must be performed as a group, that is, all of the packages must be submitted with one unified identification. This is known as group submission.

This feature is supported by the collaboration of Tizen client development tool (GBS) and Tizen backend services.

For the platform developers, GBS provide the --tag <TAG> option, to accept one developer specified "TAG" for the 'gbs submit' command. All submissions for multiple packages with the same TAG will be considered as a "group". And the package in the same "group" will be handled in the build system together.

An example is shown below:

Assuming ail, a low level libray, is depended by aul. Developers of ail has changed some APIs, and aul must be updated to adapt to new API changes of ail. Therefore, once all related patches have been merged to ail and aul separately, these two packages must be submitted as a group.

The procedure is as follows:

  1. Submit one of the packages in the group to create a tag.

    $ cd platform/core/appfw/aul-1/
    $ gbs submit -m "<Comments>"
  2. Obtain the tag name from the output of the command above, and use the same tag as parameter of --tag for other packages in the group.

    $ cd platform/core/appfw/ail/
    $ gbs submit --tag <same_tag> -m "<Comments>"

Actually, developers can also specify the tag by themselves, and use the same tag for all packages in the package group. In this case, the tag must follow the same rule in above section, or with extra postfix, like:

submit/$Tizen_Version/$(%Y%m%d.%H%M%S).N (N stand for a choiced number)

Tizen backend services will take care all submission with the same tag, and build them together.

3.3 Reviewing a Package on the Build Server (for release engineer only)

After developers run gbs submit command, Tizen back-end service starts the pre-release and nornal release processes at the same time. During the pre-release process, packages and Tizen images with specific package inside are presented to release engineers and Quality Assurance (QA) engineers for review.

QA engineers are responsible for testing packages as isolated objects, as well as verifying Tizen images with specific package inside to offer release engineers comprehensive information to make appropriate decision about whether to accept or reject a package, including the following:

  • Whether this package impacts other dependent package build.
  • Whether this package brings in new bugs.
  • Whether this package causes regression issue.
  • Whether this package influences the performance of Tizen image.

After packages are accepted by release engineers, the corresponding images are automatically created by the normal release process and can be obtained on