Code Contribution Process

• For features - open a RDKDEV (for video or generic contributions) or RDKBDEV (for Broadband contributions)
• Clone the component code from rdk-next branch
• Apply changes 
• Push the patch to Gerrit for review
• Trigger reviews and handle review comments
• Change set trigger: Use TDK for validation and BlckDuck scan for license compliance

Step 1  Developer  to create  RDKDEV/RDKBDEV tickets

• Log in to JIRA https://jira.rdkcentral.com/jira/secure/Dashboard.jspa using rdkcentral credentials
• Click on the Create button

Step 2  Developer clones component

Developer clones component repository from Gerrit server  https://code.rdkcentral.com/r/ into local work space

Step 3  Developer works on the change

• The Developer creates a topic branch in the local work area, makes the necessary changes and then squashes the commits prior to pushing for review.

Step 4 Gerrit for review

Developer pushes the new change to Gerrit for review, i.e. to refs/for/master

• When interfacing with Gerrit you push to a virtual branch, /refs/for/<branch>, representing "code review before submission to branch".
• Gerrit will subsequently assign a unique URL for the change, to facilitate access and review via the web UI.

Step 5,6,7

Review notifications and addition of new reviewers.

• The Developer may request feedback by adding additional reviewers via the Gerrit web GUI or command line.
• Component owners/reviewers/approvers, defined as specific groups in the external LDAP system, will be added by default

Post Checkin process

Run BlackDuck, copyright scanning and build on code submission.
• If applicable, BlackDuck, copyright scanning and build jobs will be triggered from Jenkins.
• The output of these jobs is integrated into the Gerrit voting process via custom labels and will reflect any 'red flag' in a file that has new code changes, whether introduced in the new Change/Patch Set or      not.

Code review and scoring process

Reviewers can comment on and score a given change.
• The default set of rules for enabling a code change for submission requires a Code Review score of +2 and a +1 score on any mandatory Gerrit labels configured for the project.
• The result of the scoring process and validation rules is to enable the Submit action on the Gerrit Web UI and subsequent merge capability to the target branch.
   +2 Value approval
   ‐2 Do not submit.
   +1 Enables a submit
   ‐1 Block a submit

Step 8 Submit change

Submit change

• Only authorized users i.e. component owners and component approvers can submit the change allowing Gerrit to merge it to the target branch as soon as possible.
• A change can be submitted, having satisfied the approval conditions described earlier, by clicking the 'Submit Patch Set n' button within the Gerrit UI.

Abandon change.

• A conscious decision is made to abandon the change based on the review outcome.
• The component owner or an authorized user may abandon the change by clicking the "Abandon Change" button.
• The abandoned changes are not removed from the Git repository and could be restored at a later stage.

Submitted, Merge Pending

• The change depends on another change that is still in review.
• In this case the change will be merged automatically once all its dependencies are submitted and merged

Step 9 Change needs to be reworked

where the numbering scheme for fetching the changes is as  follows:
refs/changes/<last two digits of change number> <change number> <patch set number>

A new patch set is now appended to the Gerrit review item, and  this will go through the same review process as before.

Step 10: Gerrit conflict resolution

• Rebase the local branch to the latest state of origin/master;
• Resolve all conflicts;
• Commit with the `--amend` option;
• Push changes to Gerrit for review.

After this change a new patch set is created for the change.