Source Code Management (GIT/Gerrit)
Git is the main source code management (SCM) tool for Tizen. Gerrit is the code-review system. Developers can use Gerrit's GUI to manage their Git projects and perform code reviews.
Build engine (OBS)
OBS (Open Build Service) is the main production build engine, as it was with Meego. However, developers cannot submit code directly to OBS. Instead, custom tools have been created, for the developer's convenience, that submit directly to OBS through Git. Developers can also perform local builds and sandbox builds using these tools.
For more information on each tool:
- Git/Gerrit: https://review.tizen.org/gerrit
- OBS: https://build.tizen.org/
- Jira: https://bugs.tizen.org/jira
- Tizen downloads: http://download.tizen.org/
There are two possible branches for a given project in the Git repository: Upstream and Master (development). The Master Branch is the only one required for all Git projects.
Here are the branch descriptions:
- 1. Upstream Branch (optional)
- Hosts expanded pristine source, do not put local Tizen changes in this Upstream Branch (also, no .spec, .tar, or .patches here).
- Optional branch: The Upstream Branch can be used by developers who have an upstream Git project they are basing their project on. However, if the upstream project is using a different SCM tool (like cvs or svn), or if the developer would rather use another Git service to host their own upstream sources (like Github), then do not create an Upstream Branch for the project.
- 2. Master Branch
- The Master Branch (or "development branch") hosts each project’s full source tree (all c/c++ and .h files, makefile, and so on). This is where developers manipulate files and change source code. This branch includes expanded upstream source and Tizen local changes.
- Each git project will maintain a '/packaging' folder that contains packaging files and information.
- Developers need to maintain the packaging changelog within the '/packaging' folder of each git tree.
To submit code from a source repository to OBS, use tools to perform the two steps below: creating the tarball, and organizing all packaging files together:
- 1. Create a tarball
- Create the tarball using 'git-archive'. The ‘/packaging’ directory must included in the tarball, as well.
- The tarball version is abstracted from the spec file by ‘rpmbuild’.
- 2. Take the contents of the packaging directory and put them alongside the tarball.
Code submission flow
This image shows the code development and packaging submission flow.
- Code review
- All Tizen developers can review code, but only those listed as Tizen reviewers in Gerrit can approve changes.
- Master Branch to production tree
- Any time a developer's change is accepted into the Master Branch, it is considered a submission to the production tree.
- If developer wants to submit code to the build system, the developer needs to update the changelog, create a new tag, and push to Gerrit review. After the review is passed, the backend service creates a Submit Request (SR) and submits the change to OBS.
- Gerrit Review to OBS submission
- When a Gerrit review is accepted into the Master Branch, tools directly commit the change to a staging area in OBS.
- When a Gerrit review is accepted into the Master Branch, and the change contains the changelog update and tag, tools generate an SR in the OBS production project.
- Release Engineers accept SRs
- Release Engineers (REs) review and accept SRs
- SR reviews by REs target mainly integration timing controls, which normally have no rejections. If a rejection happens, the RE will hold the following SR acceptance for the same package until the developer submits the fix for that rejection.
Git projects map to OBS pkgs
Every package in OBS has its own Git repository, and branches map to a project in OBS.
- The Master Branch of the 'foo.git' package should map to the 'foo' package in 'Trunk' in OBS.
- The Tizen_1.0 branch of the 'foo.git' package should map to the 'foo' package in 'Tizen:1.0' in OBS.
When a change is submitted and accepted in one branch, the backend monitors the change, creates the SR, and submits to the target project appropriate for that branch.
Here is a table describing this mapping: