for maintainers

This page describes some tasks that regular developers and maintainers of the ASGarD codebase may be asked to perform.

Handling pull requests

Here is an outline of the process:

1. PR comes in for 'develop'
2. CI and Gitlab checks
   • if clean merge or CI failures go unanswered, maintainer asks submitter to fix, and eventually rejects PR.
3. maintainer does quick sanity checks
   • patch is reasonably sized (smallest possible complete logical feature)
   • code formatting
   • well commented/documented
4. Submitter addresses comments from maintainer(s)
5. If required, maintainer tags project developer(s) to review and comment
6. Submitter addresses comments from developer(s)
7. At least one reviewer must mark the PR as "approved" on Gitlab, indicating they have reviewed the code.
8. Once developers, requested reviewers, and maintainers give '+1', thumbsup, okay, whatever, maintainer continues with merging the pull request into develop.

Code reviews

If you are asked to review a pull request, please try to have your comments or approval in by the same time (24hrs) of the next business day. This will help to keep discussion active. Once you are done reviewing, please mark the PR as approved in the Gitlab web interface.

Please refer to our code review checklist.

Note that most of these things should be handled by the PR submitter before others review the code in order to make their job easier.

Also checkout the thoughtbot guide to code-reviews.

Guidelines for Pull Request approvers

In addition to meeting the technical requirements discussed above, note the following guidelines:

1. PR approvers should not approve work they have been involved with.
2. In the event of ambiguity or uncertainty, the PR approvers should all discuss an appropriate process in advance of any approval.
3. Currently the status check requires the PR up-to-date with the develop branch. However, a merge of develop to the PR branch can cause difficulty for review. For this reason, unless there is particular concern, delay updating the PR from develop until the review process is completed.

things to be automated

These could be automated on the server side (more robust but more CI resources), or on the developer/IDE side.

• test coverage
• code formatting

Release process

1. Create a release candidate branch from develop. Set this branch as protected.
2. Update the version numbers in CMakeLists.txt
3. Update the CHANGELOG.md with major changes since last release.
4. Verify CHANGELOG.md is appropriate with contributors, interested parties. Update as needed.
5. Issue a PR to master.
6. PR approver verifies that the tests run on relevant architectures.
7. Approve the PR
8. Tag the release with the version number, e.g. 3.0.1
9. Create a release using the Gitlab release tool
10. Rebase develop onto tagged master commit with git rebase --preserve-merges
11. Delete the release candidate branch.
12. Make public announcement
13. All developers need to git fetch; git co develop; git reset --hard upstream/develop