Code Contribution Process in RDKCentral

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 : Changeset trigger and Verification

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

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

Code Contribution Process for Components hosted in RDKCentral Github

Step 1 : Fork the component from github

Sign-in to github with your own credentials.

Search for the Component.

Fork the component from github. Forking will create a copy(i.e, your own WORKSPACE) of an original component to work.

Step 2 : Clone the Component

Click on the "Clone or download" button to get the clone url from github. Ensure your github username present in the url to start work with your own workspace.

Step 3 : Work on changes and Gerrit commands to push the changes

Make the code changes, and commit the changes

$ git add .
$ git status
$ git commit -m "<JIRA_TICKET_ID> <COMMIT_DESCRIPTION>"
$ git push

Step 4 : Create pull request for review the changes

Once submitted the changes need to create pull request from github for review. Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

• Click on "New pull request" button.

• Click on "Create pull request" button.

• Provide the commit request and Click on "Create pull request" button.

Pull Request page will be created.

Step 5 : Working on review comments

Once you've created a pull request, you can push commits from your workspace to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab.

Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.