Add a resolution about stable branch EOL and "extended maintenance"
We've talked about this for years, and talked some more at the Rocky PTG. This adds a resolution to try and document / summarize the outcomes of the Sydney summit and Rocky PTG. Change-Id: I94b0421d8a489026300789b61b0293dd2e61726d
This commit is contained in:
Matt Riedemann
parent
e591b824b3
commit
4cd1fc03ec
@ -30,6 +30,7 @@ sys.path.insert(0, os.path.join(os.path.abspath('.'), '_exts'))
|
|||||||
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
|
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
|
||||||
extensions = [
|
extensions = [
|
||||||
'sphinx.ext.extlinks',
|
'sphinx.ext.extlinks',
|
||||||
|
'sphinx.ext.todo',
|
||||||
'atcs',
|
'atcs',
|
||||||
'members',
|
'members',
|
||||||
'projects',
|
'projects',
|
||||||
|
|||||||
144
resolutions/20180301-stable-branch-eol.rst
Normal file
144
resolutions/20180301-stable-branch-eol.rst
Normal file
@ -0,0 +1,144 @@
|
|||||||
|
===================================================
|
||||||
|
2018-03-01 Extended maintenance for stable branches
|
||||||
|
===================================================
|
||||||
|
|
||||||
|
The OpenStack `stable branch maintenance team`_, among other teams such as
|
||||||
|
`QA`_, `infra`_, `vulnerability management team (VMT)`_, the `release team`_,
|
||||||
|
alongside users, operators, vendors and distributions, have talked for years
|
||||||
|
about extending the life of the stable branches.
|
||||||
|
|
||||||
|
There was a cross-project discussion about this during the Newton summit:
|
||||||
|
|
||||||
|
https://etherpad.openstack.org/p/stable-branch-eol-policy-newton
|
||||||
|
|
||||||
|
And another at the Queens summit:
|
||||||
|
|
||||||
|
https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
|
||||||
|
|
||||||
|
There have been discussions about stable branch end of life, release process,
|
||||||
|
long-term support releases, etc, at every face-to-face event (PTG, summit)
|
||||||
|
for years.
|
||||||
|
|
||||||
|
This resolution does not intend to cover all of the history, viewpoints,
|
||||||
|
use cases, caveats, etc - it would never end. The purpose of this resolution
|
||||||
|
is to summarize and state the stance of the various upstream stable branch
|
||||||
|
maintainers and related teams (mentioned above) with respect to extended
|
||||||
|
maintenance windows for stable branches and their end of life process.
|
||||||
|
|
||||||
|
The first branch this will apply to is stable/ocata.
|
||||||
|
|
||||||
|
End of life
|
||||||
|
-----------
|
||||||
|
|
||||||
|
The stable branches shall remain open to accept fixes as long as reasonably
|
||||||
|
possible. Codifying when a branch can no longer be maintained is not within
|
||||||
|
the scope of this resolution, but it typically means no one is maintaining
|
||||||
|
the branch, it is not tested and fixes cannot merge.
|
||||||
|
|
||||||
|
The current end of life process of applying the ``<branch>-eol``
|
||||||
|
tag and deleting the branch, cleaning up related infra scripts, etc, will
|
||||||
|
change to not delete the branch. Instead, a ``<branch>-em`` tag will be
|
||||||
|
applied on the final release indicating the branch is now in
|
||||||
|
*extended maintenance (EM)* mode.
|
||||||
|
|
||||||
|
If at some point fixes cannot land in a given project and there is no
|
||||||
|
reasonable solution, then the branch will need to be EOL for that project.
|
||||||
|
Note that it is possible for our CI infrastructure to `function based on EOL
|
||||||
|
tags`_.
|
||||||
|
|
||||||
|
Releases
|
||||||
|
--------
|
||||||
|
|
||||||
|
The upstream stable branch maintenance team shall maintain and release each
|
||||||
|
branch for typically 18 months, which has been the historical lifespan of a
|
||||||
|
branch in OpenStack. After that, there will be no releases as a release
|
||||||
|
would indicate the same level of support from the upstream teams, which may
|
||||||
|
not be the case. Contributors can continue to push fixes and they can be
|
||||||
|
merged but they will not be released upstream.
|
||||||
|
|
||||||
|
Keep in mind that the overarching goal of this resolution is to provide a
|
||||||
|
common place (and infrastructure) for deployers, contributors and vendors
|
||||||
|
to share and get fixes for older branches. It is not to indefinitely extend
|
||||||
|
the same level of upstream support for all branches for all time.
|
||||||
|
|
||||||
|
Support phases
|
||||||
|
--------------
|
||||||
|
|
||||||
|
The traditional `support phases`_ may change as a result of this resolution
|
||||||
|
but the details are out of scope for this document, and any changes would be
|
||||||
|
part of the stable branch guidelines documentation.
|
||||||
|
|
||||||
|
Note that the traditional **Phase III** for stable branch maintenance may be
|
||||||
|
dropped since its purpose was mostly to highly restrict applicable fixes to a
|
||||||
|
branch that will soon be end of life. In other words, teams must take extra
|
||||||
|
care to not backport regressions to a branch before it is EOL and then
|
||||||
|
cannot be fixed upstream.
|
||||||
|
|
||||||
|
With the removal of EOL after 18 months, the need for Phase III type
|
||||||
|
restrictions is severely reduced to the point of no longer being necessary.
|
||||||
|
|
||||||
|
.. note:: VMT coverage for EM branches would be on a best-effort basis due
|
||||||
|
to the confidence of the VMT being able to research a
|
||||||
|
vulnerability's presence in very old EM branches or that
|
||||||
|
backported security fixes to said branches actually address the
|
||||||
|
vulnerability there.
|
||||||
|
|
||||||
|
Core teams
|
||||||
|
----------
|
||||||
|
|
||||||
|
The stable branch core teams will remain unchanged between EM and non-EM
|
||||||
|
branches. If people are doing good work on the EM stable branches, then
|
||||||
|
they likely should be included in the regular stable branch core team for
|
||||||
|
the project.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
-------
|
||||||
|
|
||||||
|
The EM branches will continue to run the same level of CI testing after
|
||||||
|
the standard 18 month window, as long as feasible.
|
||||||
|
|
||||||
|
Tempest is branchless and has historically dropped support for testing
|
||||||
|
older branches once they are end of life. This allows Tempest (and devstack)
|
||||||
|
to drop compatibility code and other technical debt.
|
||||||
|
|
||||||
|
Once a branch enters extended maintenance mode, the QA team *may* move
|
||||||
|
forward with changes that disrupt an old branch if those changes cannot be
|
||||||
|
easily made another way. This resolution will not attempt to predict or
|
||||||
|
codify what those types of changes might be, or how maintenance on older
|
||||||
|
branches can be extended and still run integration tests with Tempest. The
|
||||||
|
point is the QA team can move forward and not be hindered by the extended
|
||||||
|
maintenance of the stable branches.
|
||||||
|
|
||||||
|
In other words, these older branches might, at some point, just be running
|
||||||
|
pep8 and unit tests but those are required at a minimum.
|
||||||
|
|
||||||
|
Appropriate fixes
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Backports to these branches must follow the upstream
|
||||||
|
`stable branch maintenance guide`_. This includes but is not limited to:
|
||||||
|
|
||||||
|
* Bug fixes only. Features will not be accepted on stable branches.
|
||||||
|
* Backports must go in order from the newest branch where the bug exists.
|
||||||
|
This means if a bug is to be fixed in Ocata, it must also be fixed first
|
||||||
|
in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot
|
||||||
|
skip branches lest people would upgrade and be regressed.
|
||||||
|
* Project teams should not block proposed fixes for a branch based on the
|
||||||
|
non-technical merit of the proposed branch.
|
||||||
|
* Following on the last point, projects teams will not pick and choose EM
|
||||||
|
branches. For example, a project shall not say that Ocata and Queens can
|
||||||
|
have extended maintenance but Pike will not.
|
||||||
|
|
||||||
|
It is worth noting that the stable branch maintenance guide provides
|
||||||
|
guidelines for appropriate fixes, but each backport should be judged on its
|
||||||
|
own by the core team based on relative risk versus severity of the bug being
|
||||||
|
fixed.
|
||||||
|
|
||||||
|
.. _stable branch maintenance team: https://governance.openstack.org/tc/reference/projects/stable-branch-maintenance.html
|
||||||
|
.. _QA: https://governance.openstack.org/tc/reference/projects/quality-assurance.html
|
||||||
|
.. _infra: https://governance.openstack.org/tc/reference/projects/infrastructure.html
|
||||||
|
.. _vulnerability management team (VMT): https://docs.openstack.org/project-team-guide/vulnerability-management.html
|
||||||
|
.. _release team: https://governance.openstack.org/tc/reference/projects/release-management.html
|
||||||
|
.. _function based on EOL tags: https://review.openstack.org/#/c/520095/
|
||||||
|
.. _support phases: https://docs.openstack.org/project-team-guide/stable-branches.html#support-phases
|
||||||
|
.. _stable branch maintenance guide: https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
|
||||||
Loading…
Reference in New Issue
Block a user