Code Contribution

...

Workflow

• New deployment Deployment ready Branch Product Branch has been created for RDK components that the community will push changes to review

  With higher

  & It is with higher standards of test qualification

• Monthly Sprint Branch (rdk-dev-yymm) is a new CMF integration branch, created monthly and baselined off rdk-nextbaseline off Product Branch Branch. This branch will be hosted per repository in conjunction with rdk-next, Product branch with the goal of incorporating community changes at the earliest juncture.
• Community changes, once approved, will be cherrypicked to cherry-picked to Monthly Sprint branch (rdk-dev-yymm and ) and will thus be available prior to the completion of down-streaming/ round-trip process.
• Approved contributions will be down-streamed to Sprint Regression Branch for Branch for pre-deployment validation using their test process
  • Defects will be planned in monthly sprints
  • Features will be presented for Architecture Review to be scheduled to an upcoming sprint. Sprint timelines to be published to contributor.
  • Contributions pending validation will be available in monthly development iteration branches
• Downstreamed Down streamed Community changes, successfully merged to Sprint Regression branch, after pre-deployment test validation, the code changes will be cherry-picked to production/release branch (rdk-next) Product Branch. 

Code Contribution Workflow Diagram

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

Image Removed

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.

1. User will do code contribution to rdk-next branch. This will undergo:
   1. Code reviews
   2. Build verification
   3. License compliance scan
   4. Test validation
2. Once successful, the change will get cherry-picked to Monthly Sprint Branch (rdk-dev-yymm)
3. This code is then down-streamed to Regression Branch where pre-deployment test validation are done
4. Once Comcast accepts, the change-set is cherry picked to Product Branch.
5. Thus the change gets merged to Product Branch

...

Component owners/reviewers/approvers, defined as specific groups in

...

Gerrit, will be added

...

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

...

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

...

git checkout -b topic_branch
git fetch https://user@code.rdkcentral.com/r/rdk_component_1 refs/changes/58/58/2 && git checkout FETCH_HEAD
git rebase origin/master

[Edit the conflicting file, cleaning up the <<<<, ==== >>> markers surrounding the conflicting lines]

to the review by default. You may request additional feedback by specifically adding reviewers via the Gerrit web GUI. 

Product Branch

Product branch is a deployment ready branch is created for RDK components that the community will push changes to review.

Refer to Product Branch for the Components hosted in CMF Gerrit (https://code.rdkcentral.com)

Refer to RDK Central GitHub Components & its Branches hosted in https://github.com/rdkcentral/

Monthly Sprint Branch

Monthly Sprint Branch (rdk-dev-yymm) is a new CMF integration branch, created monthly and baseline off Product Branch. This branch will be hosted per repository in conjunction with Product branch with the goal of incorporating community changes at the earliest juncture.

Once community changes is  approved, will be cherry-picked to Monthly Sprint branch (rdk-dev-yymm) and will thus be available prior to the completion of down-streaming to Regression Branch / round-trip process.

Regression Branch

Regression branch is the branch used for validation of the contributions. Approved contributions will be down-streamed to Regression Branch for pre-deployment validation using their test process.

• Defects will be planned in monthly sprints
• Features will be presented for Architecture Review to be scheduled to an upcoming sprint. Sprint timelines to be published to contributor.
• Contributions pending validation will be available in monthly development iteration branches

Down streamed Community changes, successfully merged to Regression branch, after pre-deployment test validation, the code changes will be cherry-picked to Product Branch. 

Code Submission Process

Code Submission Process - RDK Central Gerrit

Code Submission Process - RDK Central GitHub

...

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

Image Removed

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.

...

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

Image Removed

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.

Image Removed

Image Removed

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.

Image Removed

• Click on "Create pull request" button.

Image Removed

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

Image Removed

Pull Request page will be created.

Image Removed

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.