CMF
RDK Releases
Documentation
CMF Videos
Support
Support for CMF is provided by the RDK Support group.
To contact RDK Support:
Enter a ticket: https://jira.rdkcentral.com/
or
E-mail: support@rdkcentral.com
...
The master source is hosted at code.rdkcentral.com. You can submit your changes for review via that site using the workflow outlined below.
Table of Contents |
---|
A new deployment ready branch “rdk-next” has been created with higher standards of test qualification
rdk-next-branch | rdk-dev-yymm branch |
---|---|
Quarterly releases Deployment ready code Pre-Deployment tests | Monthly Iteration releases Reviewed by component owners Tested with Reference platforms |
...
A brief summary about what we are trying to contribute
A descriptive information about the contribution should be present so that component developers & architecture team can do assessment of the feature. Below details are desirable if the contribution is a new feature or having an significant impact on the current architecture.
Solution Overview |
---|
Brief introduction on what the current system lacks & what needs to be done: 1. Individual task/highlighted point #1 brief description. |
Architecture Checklist |
---|
The following items should be considered/addressed in the documentation for any RDK design initiative
JIRA Update Checklist
----------------------- The following JIRA fields MUST be filled in to be considered "Definition Complete": RDK SoC, RDK OEM - populate these fields for any user story where we have dependency on OEM and/or SoC OEM/SoC Impact Details - description of impact (or "see Solution Overview" if included in the architecture specification)
* Platforms - ensure correct list of devices
* Validation - type of testing
* Regression - is regression required?
* Impacted Party - Comcast Only, Syndication, etc.
* Dependency - Internal/External
* Description - Solution Overview and Architecture Checklist
Testing impact/Guidance ------------------------
* Impacted modules
* Test process
Automated Testing
------------------ * Automation test procedure.
Diagnostics, Telemetry and Logging
----------------------------------- * N/A
Outbound Network Connections
------------------------------ * Does this component make outbound connection requests?
* If yes, do the connection requests retry in the case of failure?
** Do the repeated requests use an exponential back-off?
** If a maximum back-off has been defined, is it greater than 10 minutes?
Security
---------- * For Security Review - Do feature elements:
** make any changes to network port assignments?
** change iptables rules?
** require credentials, passwords, secret data?
** make any changes to our network connections?
** connect to new services or servers?
** use data input from users or external tools?
** use any cryptographic functions?
** create or disclose proprietary or sensitive Co. or device data?
** properly log operational and configuration changes?
** If possible describe what could happen if feature elements are:
*** spoofed?
*** tampered with?
*** used by an unauthorized actor?
** Advanced questions (optional)
*** what happens if a record of actions taken is destroyed?
*** what happens if an attacker attempts to DOS with the feature?
SI Concerns
------------- * Yes/No/Any
Performance expectations
------------------------- * Yes/No/Any
Timing consideration
---------------------- * If Any. |
...
No Format |
---|
<JIRA TICKET #1>, <JIRA TICKET #2>, <JIRA TICKET #n> : <one line summary of change>
<empty line>
Reason for change: <explanation of change>
Test Procedure: < test procedure>
Risks: <side effects and other considerations> [Note: state None if there are no other considerations]
<empty line>
Signed-off-by: Your Name <your_name@email.com> |
...
Labels: Blackduck/Copyright/Component-Build (Highlighted in yellow color) For a change to be mergeable, the change must have a '+1' score on these labels, and no '-1 Fails'. Thus, '-1 Fails' can block a submit, while '+1' enables a submit.
! Review input is generally referred to as labelling with a positive/negative score. |
---|
7. Submit change
Only authorised users, i.e. component owners, component approvers or admins, 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. When a change has been Submitted, it is automatically merged to the target branch by Gerrit.
...
refs/changes/<last two digits of change number> <change number> <patch set number>
! Gerrit will specify this fetch URL via the web UI on the 'Download' link on the review page for the change in question, you just paste it into the command line. |
---|
Next, make any necessary source changes, and do:
...
A new patch set is now appended to the Gerrit review item, and this will go through the same review process as before.
!
|
---|
11. Gerrit merge failure as a result of a conflict
...