This patch continues to incorporate review comments on the stable
maintenance document
- removing trailing whitespaces
- comment 1 by Jonas about allowing minor version of an upstream project
- comment 2 by Jonas about how committers are elected
Change-Id: I7c4b72a2058e9814ebdcb5a1f925f5a20a6551ec
Signed-off-by: Uli Kleber <ulrich.kleber@huawei.com>
A number of factors must be weighed when considering a change:
A number of factors must be weighed when considering a change:
-- **The risk of regression** - even the tiniest changes carry some risk of
+- **The risk of regression** - even the tiniest changes carry some risk of
breaking something and we really want to avoid regressions on the stable branch
breaking something and we really want to avoid regressions on the stable branch
-- **The user visible benefit** - are we fixing something that users might actually
+- **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
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
- 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.
- 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.
+- Since OPNFV is using several upstream projects, typically fixes in the upstream projects will apply as fixes for OPNFV. Therefore complete **maintenance revisions of the upstream projects** (i.e. minor versions) can be used as suitable backports for OPNFV maintenance releases.
- 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.
- 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.
- Changes to the notification definitions
- DB schema changes
- Incompatible config file changes
- Changes to the notification definitions
- DB schema changes
- Incompatible config file changes
-- Changes including a version upgrade of an upstream component of OPNFV
+- Changes including a version upgrade of an upstream component of OPNFV
(since this will typically violate the above points)
Support phases
(since this will typically violate the above points)
Support phases
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 log (find out the commit id of the patch that you want to backport from "git log" output)
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 log (find out the commit id of the patch that you want to backport from "git log" output)
- $> git checkout stable/arno
- $> git cherry-pick -x $master_commit_d
+ $> git checkout stable/arno
+ $> git cherry-pick -x $master_commit_d
$> git review stable/arno
Note: cherry-pick -x option includes 'cherry-picked from \85' line in the commit message which is required to avoid Gerrit bug
$> git review stable/arno
Note: cherry-pick -x option includes 'cherry-picked from \85' line in the commit message which is required to avoid Gerrit bug
Email Notifications
~~~~~~~~~~~~~~~~~~~
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
+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
click "Watched Projects"
Project Name: All-Projects
Project specific tasks
~~~~~~~~~~~~~~~~~~~~~~
Project specific tasks
~~~~~~~~~~~~~~~~~~~~~~
-Each of the 5 projects that contributed to Arno will dedicate some committers which would be in charge of reviewing backports for their project, following the stable branch policy.
+Each of the 5 projects that contributed to Arno will dedicate some committers which would be in charge of reviewing backports for their project, following the stable branch policy. It is in the responsibility of each project how to select those committers (e.g. vote in the team).
The group of these committers here are sometimes called the "stable branch maintenance team" or "stable-mtc" without this being necessarily a team with own organization.
The group of these committers here are sometimes called the "stable branch maintenance team" or "stable-mtc" without this being necessarily a team with own organization.