...

Code Contribution Process

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

• With higher Release branch is 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 Release Branch. This branch will be hosted per repository in conjunction with rdk-next, with Release 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 productionProduction/release Release branch (rdk-next). 

Workflow Diagram

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

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

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.

...

...

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

...

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]

Release Branch

Regression Branch

...

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

...