Code Contribution Process

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

 Uses TDK for component validation 

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,9,10 : About Changeset

Changeset 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.

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.

Step 11 : JIRA ticket status update

• After patch set trigger, Corresponding JIRA  https://jira.rdkcentral.com/<ticket_number> will get reflected with the commit details.

Step 12 : CMF build & test

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

Once the changes got merged in CMF, ticket will gets automatically updated with those information.