Release Process

PR reviews

The master branch is integrated with Pull Approve. This provides a neat way to encapsulate our review process in an automated fashion:

• All tests much pass before a PR is approved.
• All commits must have a "Signed-off-by" entry.
• Two Team members are required to review and approve every PR.

The file which controls this process is .pullapprove.yml.

How to mark a PR as approved

If you review a PR and decide it should be approved, add one of the following "special comments" at the start of a line:

• lgtm
• LGTM
• +1
• Approve
• Approved

Correct: this will be considered as an approval

lgtm.

Correct: this will be considered as an approval because the line still starts with "lgtm"

lgtm. I love the way you implemented the foo() function! :-)

Incorrect: this will NOT count as an approval

This line contains the same lgtm string. But, because the "lgtm" doesn't start at the beginning of a line,
it will not count as an approval.

---

Continuous Integration (CI)

Travis is employed for our CI process. Every commit to the master branch is tested by Travis to ensure the code builds and all unit and functional tests in the tests/ directory in the git repository pass successfully.

Further, all branches that have associated PRs (Pull Requests) associated with them are expected to build cleanly in Travis before the PR will be merged.

On a daily basis, our QA team will take the latest commit in the master branch and run a further barrage of tests on it. If those tests pass, they will push a "daily tag" which is a git tag in ISO-8601 format (YYYY-MM-DD). They will also trigger a daily Coverity Scan by merging the tested master commit into the coverity_scan branch.

Periodically, an Open Build Service (OBS) run will be triggered to generate new distribution-specific packages.