The stable branch is intended to be a safe source of fixes for high impact bugs and security issues which have been fixed on master since a given release. It allows users of release (stable) versions to benefit from the ongoing bugfix work after the release.
Official point releases for each project are published from the branch on a per need basis, as decided by the TSC. In later stages, a regular cadence for point releases may be introduced.
It's possible to check current maintained versions in the releases page.
OPNFV's stable branch policy borrows much from prior art, in particular from OpenStack and OpenDaylight.
In general all fixes should be made on the main branch and cherry-picked to stable. If there is a case where the fix is not able to be merged backwards only then we would need to do any work directly on stable. The documented method for getting a fix into stable should be by a cherry-pick process.
Only a limited class of changes are appropriate for inclusion on the stable branch.
A number of factors must be weighed when considering a change:
Some types of changes are completely forbidden:
Support phases will be introduced at a later time.
Each backported commit proposed to gerrit should be reviewed and +2ed by committer(s) of the corresponding projects.
If unsure about the technical details of a given fix, contributors should consult with the committers from the affected projects for a more detailed technical review.
If unsure if a fix is appropriate for the stable branch, at this time the TSC will do the final decision.
Fixes for embargoed security issues receive special treatment. These should be reviewed in advance of disclosure by committers. At the time of coordinated public disclosure, the fix is proposed simultaneously to master and the stable branches and immediately approved.
Anyone can propose a cherry-pick to the project committers.
One way is that if a bugfix on master looks like a good candidate for backporting - e.g. if it's a significant bug with the previous release - then just nominating the bug for the maintenance will bring it to the attention of the maintainers.
If you don't have the appropriate permissions to nominate the bug, then send an email via the user list.
The best way to get the patch merged in timely manner is to send it backported by yourself. To do so, you may try to use "Cherry Pick To" button in Gerrit UI for the original patch in master. Gerrit will take care of creating a new review, modifying commit message to include 'cherry-picked from …' line etc.
If the patch you're proposing will not cherry-pick cleanly, you can help by resolving the conflicts yourself and proposing the resulting patch. Please keep Conflicts lines in the commit message to help reviewers! You can use git-review to propose a change to the stable branch with:
$> git checkout stable/arno
$> git cherry-pick -x $master_commit_d
$> git review stable/arno
Note: cherry-pick -x option includes 'cherry-picked from …' line in the commit message which is required to avoid Gerrit bug
Failing all that, just ping one of the team and mention that you think the bug/commit is a good candidate.
When cherry-picking a commit, keep the original Change-Id and gerrit will show a separate review for the stable branch while still allowing you to use the Change-Id to see all the reviews associated with it.
Hint: Change-Id line must be in the last paragraph. Conflicts in the backport: add a new paragraph, creating a new Change-Id but you can avoid that by moving conflicts above the paragraph with Change-Id line or removing empty lines to make a single paragraph.
If you want to be notified of these patches you can create a watch on this screen:
https://gerrit.opnfv.org/gerrit/#/settings/projects
click "Watched Projects"
Project Name: All-Projects
Only If: branch:<stable branch of your choice>
Then check the "Email Notifications - New Changes" checkbox. That will cause gerrit to send an email whenever a matching change is proposed, and better yet, the change shows up in your 'watched changes' list in gerrit.
will be introduced when we see the need.
Octopus team will setup separate pipeline for stable branches.
TBD.