RDK7 HotFix Scenarios

1

A new component TAG is required for support/rdk7-main

This is the preferred mechanism

•Other unrelated changes may also be part of the new TAG and introduce regressions, compatibility issues or unwanted features

2

Fix is first applied on develop and a PR then raised on support/rdk7-main

•Develop code may have moved on so fix does not apply cleanly on release branch, an intermediate feature branch may be needed to apply the fix before bringing to support/rdk7-main

3

Fix is applied on support/rdk7-main and brought to develop at same time

Should only be allowed if component owner has approved the fix for develop and if there is going to be a delay in getting the fix on develop

•The fix may need to be different on both branches

•Time to get fix on develop

•If fix or feature is rejected by component owner then further discussions will be required

4

Fix is applied on support/rdk7-main only

Only allowed if the fix is no longer applicable on develop, e.g. code has been removed from develop

•Needs careful management to ensure that the fix is really not applicable on develop (via RCB and component owners)