Differences

This shows you the differences between two versions of the page.

--- releases:stablebranch [2015/06/18 15:25]
Ulrich Kleber [Proposing fixes]
+++ releases:stablebranch [2016/01/05 12:17] (current)
Fatih Degirmenci Simplify by remove stable-mnt team stuff. Added cherry pick via gerrit ui taken from OpenDaylight,
@@ Line 1: / Line 1: @@
-====== Stable Branch ======
+====== Overview of Stable Branch Handling ======
-Draft proposal for way of working with stable branches and doing maintenance \\ The page is derived from https://wiki.openstack.org/wiki/StableBranch , simplified and adapted to OPNFV.
-At this time only Arno release maintenance is covered.
-===== Overview =====
 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.
@@ Line 11: / Line 5: @@
 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. At this time only Arno is maintained.
+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.
+OPNFV's stable branch policy borrows much from prior art, in particular from OpenStack and OpenDaylight.
-===== Stable branch policy =====
+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**.
-==== Appropriate fixes ====
+====== Stable branch policy ======
+===== Appropriate fixes =====
 Only a limited class of changes are appropriate for inclusion on the stable branch.
@@ Line 25: / Line 22: @@
   * **The user visible benefit** - are we fixing something that users might actually notice and, if so, how important is it?
   * **How self-contained the fix is** - if it fixes a significant issue but also refactors a lot of code, it's probably worth thinking about what a less risky fix might look like
-  * Whether the fix is already on master - a change must be a backport of a change already merged onto master, unless the change simply does not make sense on master.
+  * Whether the fix is **already on master** - a change must be a **backport** of a change already merged onto master, unless the change simply does not make sense on master (e.g. because of a change of architecture).
+  * If there is a suitable **work-around** for a bug, normally there won't be a fix on stable.
-Rules to maintain multiple versions and exceptions will be added later.
+  * Since OPNFV is a midstream integration effort, also **test cases** might be suitable backports in case they are related to critical bugs found in stable.
-The stable review team needs to balance the risk of any given patch with the value that it will provide to users of the stable branch. A large, risky patch for a major data corruption issue might make sense. As might a trivial fix for a fairly obscure error handling case.
 Some types of changes are completely forbidden:
@@ Line 38: / Line 33: @@
   * DB schema changes
   * Incompatible config file changes
+  * Changes including a version upgrade of an upstream component of OPNFV \\ (since this will typically violate the above points)
-This excludes changes that include a version upgrade of an upstream component of OPNFV.
-==== Support phases ====
+===== Support phases =====
-Support phases will be introduced at a later time
+Support phases will be introduced at a later time.
-==== Review of fixes ====
+===== Review of fixes =====
-Each backported commit proposed to gerrit should be reviewed and +2ed by two Arno-stable-maint members before it is approved. Where a stable-maint member has backported a fix, a single other +2 is sufficient for approval.
+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, stable-maint members should consult with the appropriate developers from the affected projects for a more detailed technical review.
+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.
-==== Security fixes ====
+===== Security fixes =====
-Fixes for embargoed security issues receive special treatment. These should be reviewed in advance of disclosure by committers and stable-maint. At the time of coordinated public disclosure, the fix is proposed simultaneously to master and the stable branches and immediately approved.
+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.
-===== Processes =====
+====== Processes ======
-==== Proposing fixes ====
+===== Proposing fixes =====
-Anyone can propose a cherry-pick to the stable-maint team.
+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 Arno maintenance will bring it to the attention of the maintainers.
+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.
@@ Line 71: / Line 66: @@
 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:
+==== Cherry Pick Patches from Master to a Stability Branch From Command Line ====
 $> 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 [[https://code.google.com/p/gerrit/issues/detail?id=1107|Gerrit bug]]
+==== Cherry Pick Patches from Master to a Stability Branch via Gerrit UI ====
+  - Select the patch that you want to cherry pick from Master to Stable Branch
+  - Locate the Cherry Pick To button \\ {{:stability_screenshot9.png?400|}}
+  - Start to type in "re" in the branch text box to get suggestions to appear, then select "refs/heads/stable/<release-name>" \\ {{:stability_screenshot10.png?400|}}
+  - Click Cherry Pick Change \\ {{:stability_screenshot11.png?400|}}
 Failing all that, just ping one of the team and mention that you think the bug/commit is a good candidate.
-==== Change-Ids ====
-==== Email Notifications ====
+===== Change-Ids =====
+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.
+===== Email Notifications =====
+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.
+===== Bug Tags =====
+will be introduced when we see the need.
+===== CI Pipeline =====
-==== Bug Tags ====
+Octopus team will setup separate pipeline for stable branches.
-I don't think we need that at the moment
-===== Team organization =====
+====== Stable Branch Maintenance Team organization =====
-Find better place for following text:
+TBD.
-Existing committers are greatly encouraged to join the Arno-stable-maint team in order to help with reviewing backports, judging their appropriateness for the stable branch and approving them.
+====== References ======
+  * https://wiki.openstack.org/wiki/StableBranch
+  * https://wiki.opendaylight.org/view/Simultaneous_Release:Cutting_Stability_Branches

Wiki

User Tools

Site Tools

Differences

Page Tools