Update docs for Unmaintained
Updates the Stable Branches page of the project team guide to describe Unmaintained branches[0, 1]. [0] https://review.opendev.org/c/openstack/governance/+/888771 [1] https://review.opendev.org/c/openstack/governance/+/900940 Change-Id: I2171e5b82a15dc6462410b8fc6ecfe444b42ae10
This commit is contained in:
parent
d15861b2ff
commit
2594b26ad5
|
@ -25,10 +25,11 @@ Project stable branches will be in one of the following states:
|
||||||
* Approximately 18 months
|
* Approximately 18 months
|
||||||
* All bugfixes (that meet the criteria described below) are
|
* All bugfixes (that meet the criteria described below) are
|
||||||
appropriate. Releases produced.
|
appropriate. Releases produced.
|
||||||
- * Extended Maintenance
|
- * Unmaintained
|
||||||
* While there are community members maintaining it.
|
* While there is community interest.
|
||||||
* All bugfixes (that meet the criteria described below) are
|
* Only SLURP releases. All bugfixes (that meet the criteria
|
||||||
appropriate. No Releases produced, reduced CI commitment.
|
described below) are appropriate. No Releases produced,
|
||||||
|
reduced CI commitment.
|
||||||
- * End of Life (EOL)
|
- * End of Life (EOL)
|
||||||
* N/A
|
* N/A
|
||||||
* Branch no longer accepting changes.
|
* Branch no longer accepting changes.
|
||||||
|
@ -37,12 +38,53 @@ It is not required that all projects for a given branch transition between
|
||||||
phases at the same time. For example it's quite reasonable for the
|
phases at the same time. For example it's quite reasonable for the
|
||||||
``stable/$series`` branch of ``openstack/long-life-project`` to still be
|
``stable/$series`` branch of ``openstack/long-life-project`` to still be
|
||||||
in the Maintained phase while all other projects have transitioned to either
|
in the Maintained phase while all other projects have transitioned to either
|
||||||
`Extended Maintenance`_ or even `End of Life`_.
|
`Unmaintained`_ or even `End of Life`_.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
At this time the exact mechanism for describing and updating this state is
|
How can I tell what state a branch is in?
|
||||||
undefined but it's probable it will involved updating a meta-data in a
|
|
||||||
projects deliverable file in the :code:`openstack/releases` repo.
|
Current development branch
|
||||||
|
This is the ``master`` branch in a repository.
|
||||||
|
|
||||||
|
The project's core team (for example, ``cinder-core``) is responsible
|
||||||
|
for merging changes into this branch.
|
||||||
|
|
||||||
|
Maintained branches
|
||||||
|
These are the ``stable/$series`` branches in a repository, for
|
||||||
|
example, ``stable/2023.1``.
|
||||||
|
|
||||||
|
The project's stable core team (for example, ``cinder-stable-maint``),
|
||||||
|
which may be a subset of the core team, is responsible for merging
|
||||||
|
changes into Maintained branches.
|
||||||
|
|
||||||
|
A project's PTL or release team liaison must acknowledge proposed
|
||||||
|
releases from a Maintained branch, which are then subject to approval
|
||||||
|
by the OpenStack Release Management Team.
|
||||||
|
|
||||||
|
See :ref:`Stable maintenance teams<stable-maint-teams>` for details.
|
||||||
|
|
||||||
|
Unmaintained branches
|
||||||
|
These are the ``unmaintained/$series`` branches in a repository,
|
||||||
|
for example, ``unmaintained/xena``.
|
||||||
|
|
||||||
|
There is a global ``openstack-unmaintained-core`` team that is
|
||||||
|
responsible for merging changes into Unmaintained branches.
|
||||||
|
Optionally, an individual project may have a
|
||||||
|
``$project-unmaintained-core`` team (for example,
|
||||||
|
``ironic-unmaintained-core``) that has this responsibility,
|
||||||
|
and which may override the global team's approval power on
|
||||||
|
Unmaintained branches.
|
||||||
|
|
||||||
|
Releases are not allowed from Unmaintained branches.
|
||||||
|
|
||||||
|
Changes to Unmaintained branches are expected to be
|
||||||
|
:ref:`Appropriate Fixes<appropriate-fixes>` as described elsewhere
|
||||||
|
in this document.
|
||||||
|
|
||||||
|
End of Life
|
||||||
|
These do not exist as branches in the code repository, but can
|
||||||
|
be recreated by checking out a ``$series-eol`` tag, for example,
|
||||||
|
``train-eol``.
|
||||||
|
|
||||||
.. _Maintained:
|
.. _Maintained:
|
||||||
|
|
||||||
|
@ -59,75 +101,101 @@ responsible for all projects which asserted they follow the stable branch
|
||||||
policy.
|
policy.
|
||||||
|
|
||||||
|
|
||||||
.. _`Extended Maintenance`:
|
.. _`Unmaintained`:
|
||||||
|
|
||||||
Extended Maintenance
|
Unmaintained
|
||||||
--------------------
|
------------
|
||||||
|
|
||||||
Once a branch reaches Extended Maintenance project teams will cease producing
|
|
||||||
releases and `OpenStack Vulnerability Management`_ will be reasonable efforts
|
|
||||||
only. There is no statement about the level of testing and upgrades from
|
|
||||||
Extended Maintenance are not supported within the Community. There should not
|
|
||||||
be an expectation on the upstream community team to keep maintaining the
|
|
||||||
Extended Maintenance stable branches upstream testing. We will keep them open
|
|
||||||
as long as possible so that any operator or user will be able to backport
|
|
||||||
required fixes. Without regular comprehensive maintenance, it is quite possible
|
|
||||||
that someone proposing a backport to an EM branch will find that tests have
|
|
||||||
broken since the last successful merge. This means that tests (or test
|
|
||||||
configuration) might need to be fixed, reduced, or reconfigured before the
|
|
||||||
backport itself can be evaluated and merged. The onus for that falls on the
|
|
||||||
backporter or the group of people looking after a specific release.
|
|
||||||
|
|
||||||
The ``last release`` of the appropriate branch will be tagged as
|
|
||||||
``$series-em``, for example: https://review.opendev.org/608296/.
|
|
||||||
For all projects that follow the stable policy a patch with a ``$series-em``
|
|
||||||
tag will be automatically generated after the final release from the latest
|
|
||||||
development cycle happened. This is because this is a less busy period in
|
|
||||||
development perspective compared to feature freeze and release periods.
|
|
||||||
|
|
||||||
Tempest and its plugins are branchless and does not guarantee about
|
|
||||||
supporting the Extended Maintenance branches with their master version.
|
|
||||||
For more detail on the Tempest policy for stable branch testing refer to
|
|
||||||
`this doc
|
|
||||||
<https://docs.openstack.org/tempest/latest/stable_branch_support_policy.html>`_.
|
|
||||||
If Tempest master start breaking on Extended Maintenance branches testing then
|
|
||||||
we need to use the `last compatible version of Tempest and its plugins
|
|
||||||
<https://docs.openstack.org/tempest/latest/tempest_and_plugins_compatible_version_policy.html>`_.
|
|
||||||
To know the last compatible version of Tempest and its plugins, we need to
|
|
||||||
release the new tag with master hash (at the time of branch reaches Extended
|
|
||||||
Maintenance) with name ``$series-last`` as well as the new version number.
|
|
||||||
This will help to easily detect the last compatible versions of Tempest and
|
|
||||||
its plugins (instead of manually try and find the working version)
|
|
||||||
for testing it at upstream as well at production cloud.
|
|
||||||
Example: https://review.opendev.org/q/topic:%22tempest-plugin-stein-last%22+(status:open%20OR%20status:merged)
|
|
||||||
|
|
||||||
Members of the community interested in a given project/branch are encouraged to
|
|
||||||
engage with the appropriate stable team *early* in its life-cycle to ensure
|
|
||||||
this process runs well. In the absence of identified maintainers the project
|
|
||||||
will immediately enter the 6 month notification period as described under `End
|
|
||||||
of Life`_ below.
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
Some project teams may choose to NOT enter extended maintenance and go
|
Only SLURP branches are eligible for Unmaintained status.
|
||||||
directly to End of Life. At this point should a group wish to maintain
|
|
||||||
that branch of a project they can do so within license and trademark
|
After a branch is no longer in Maintained status, the branch is tagged
|
||||||
constraints. Some OpenStack CI testing *may* be available via `Zuul
|
``$series-eom``, the ``stable/$series`` branch is deleted, and an
|
||||||
drivers`_
|
``unmaintained/$series`` branch is created based on the ``$series-eom``
|
||||||
|
tag.
|
||||||
|
|
||||||
|
Releases are not allowed from Unmaintained branches.
|
||||||
|
|
||||||
|
By default, only the latest eligible Unmaintained branch is kept open.
|
||||||
|
To prevent an Unmaintained branch from automatically transitioning to
|
||||||
|
`End of Life`_ once a newer eligible branch enters the status, the
|
||||||
|
Unmaintained branch liaison must manually opt-in as described below for each
|
||||||
|
branch.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
For further details about the Extended Maintenance please take a look
|
An Unmaintained liaison may be appointed by the PTL, but there should not
|
||||||
at `the OpenStack governance's related resolution
|
be an expectation on the upstream community team to keep the branch open.
|
||||||
<https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html>`_.
|
Members of the community interested in a given branch are encouraged to
|
||||||
|
engage with the appropriate project team *early* in its life-cycle to ensure
|
||||||
|
this process runs well. In the absence of identified maintainers the branch
|
||||||
|
will automatically transition to `End of Life`_.
|
||||||
|
|
||||||
|
To opt-in to keep the Unmaintained branch open, the PTL or Unmaintained
|
||||||
|
liaison must -1 the appropriate patch in the ``openstack/releases`` repo to
|
||||||
|
EOL the branch. Please contact the PTL or Unmaintained liaison to show
|
||||||
|
interest in helping keep the branch open with backports and reviews.
|
||||||
|
The patch to EOL the Unmaintained branch will be merged no earlier than one
|
||||||
|
month after its proposal. Even if a PTL or liaison has voted +1 to EOL the
|
||||||
|
branch, the patch must remain open for the full grace period to permit other
|
||||||
|
community members the opportunity to volunteer to take it over.
|
||||||
|
|
||||||
|
To be eligible to opt-in, a branch must have functional CI including unit
|
||||||
|
tests for the published supported python versions for that OpenStack release.
|
||||||
|
Functional CI means all configured tests pass and do not generate errors in
|
||||||
|
Zuul.
|
||||||
|
|
||||||
|
Additionally, no SLURP branches may be skipped between the oldest unmaintained
|
||||||
|
branch and the current maintained releases. This makes sure operators have an
|
||||||
|
upgrade path from one SLURP to the next all the way to maintained releases.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
For further details about Unmaintained status, please take a look
|
||||||
|
at the OpenStack Technical Committee's resolution `Unmaintained status
|
||||||
|
replaces Extended Maintenance
|
||||||
|
<https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html>`_
|
||||||
|
as amended to define the `openstack-unmaintained-core Gerrit Group
|
||||||
|
<https://governance.openstack.org/tc/resolutions/20231114-amend-unmaintained-status.html>`_.
|
||||||
|
|
||||||
|
.. warning::
|
||||||
|
Tempest and its plugins are branchless and there is no guarantee that
|
||||||
|
Unmaintained branches will continue to be supported by the master version
|
||||||
|
of tempest or its plugins.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
For more information, see the `Tempest Stable Branch Support Policy
|
||||||
|
<https://docs.openstack.org/tempest/latest/stable_branch_support_policy.html>`_.
|
||||||
|
|
||||||
|
If Tempest master starts breaking when testing Unmaintained branches, then
|
||||||
|
we need to use the `last compatible version of Tempest and its plugins
|
||||||
|
<https://docs.openstack.org/tempest/latest/tempest_and_plugins_compatible_version_policy.html>`_.
|
||||||
|
|
||||||
|
To make the last compatible version of Tempest and its plugins available
|
||||||
|
for a particular branch, at the time the branch enters Unmaintained status
|
||||||
|
the Tempest maintainers will release a new tag at a master hash with the
|
||||||
|
name ``$series-last`` (as well as a new version number). The maintainers
|
||||||
|
of tempest plugins will also release ``$series-last`` tags for each of the
|
||||||
|
plugins.
|
||||||
|
|
||||||
|
This makes it easy for Tempest consumers who want to continue CI
|
||||||
|
testing of an Unmaintained branch (either upstream or in a production
|
||||||
|
cloud) to identify the last compatible versions of Tempest and its plugins
|
||||||
|
for that branch. It is also more reliable than requiring anyone who wishes
|
||||||
|
to use Tempest on an Unmaintained branch to manually try and find the
|
||||||
|
working version.
|
||||||
|
|
||||||
|
For an example of creating ``$series-last`` tags for Tempest and its
|
||||||
|
plugins, take a look at these Gerrit reviews:
|
||||||
|
https://review.opendev.org/q/topic:%22tempest-plugin-stein-last%22+(status:open%20OR%20status:merged)
|
||||||
|
|
||||||
.. _End Of Life:
|
.. _End Of Life:
|
||||||
|
|
||||||
End of Life
|
End of Life
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
After a project/branch becomes unmaintained or a team decides to explicitly end
|
After a branch is ineligible to remain active as Unmaintained or a team
|
||||||
support for a branch, it will become End of Life. The HEAD of the appropriate
|
decides to explicitly end support for a branch, it will become End of Life.
|
||||||
branch will be tagged as ``$series-eol`` and the branch deleted.
|
The HEAD of the appropriate branch will be tagged as ``$series-eol`` and the
|
||||||
|
branch deleted.
|
||||||
|
|
||||||
To initiate this transition, either the PTL of the given project or other
|
To initiate this transition, either the PTL of the given project or other
|
||||||
stable maintainer should:
|
stable maintainer should:
|
||||||
|
@ -141,6 +209,8 @@ stable maintainer should:
|
||||||
#. After the branch is tagged with ``$series-eol``, request the Release
|
#. After the branch is tagged with ``$series-eol``, request the Release
|
||||||
Management team to delete the branch.
|
Management team to delete the branch.
|
||||||
|
|
||||||
|
.. _appropriate-fixes:
|
||||||
|
|
||||||
Appropriate Fixes
|
Appropriate Fixes
|
||||||
=================
|
=================
|
||||||
|
|
||||||
|
@ -187,6 +257,8 @@ Anyone can propose stable branch backports. See `Proposing Fixes`_ for more
|
||||||
information on how to do that.
|
information on how to do that.
|
||||||
|
|
||||||
|
|
||||||
|
.. _stable-maint-teams:
|
||||||
|
|
||||||
Stable maintenance teams
|
Stable maintenance teams
|
||||||
========================
|
========================
|
||||||
|
|
||||||
|
@ -273,6 +345,26 @@ branches which generally includes:
|
||||||
#openstack-stable channel on OFTC IRC to answer questions or be made
|
#openstack-stable channel on OFTC IRC to answer questions or be made
|
||||||
aware of issues.
|
aware of issues.
|
||||||
|
|
||||||
|
Unmaintained branch maintenance
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
Unmaintained branches are not the responsibility of individual project
|
||||||
|
teams (though, of course, there is no prohibition against individual
|
||||||
|
project team members working on Unmaintained branches).
|
||||||
|
|
||||||
|
Instead, there is a global ``openstack-unmaintained-core`` team that has
|
||||||
|
access rights to maintain the CI running on Unmaintained branches, and
|
||||||
|
to merge appropriate changes into Unmaintained branches.
|
||||||
|
|
||||||
|
Additionally, each project may have (but is not required to have) a Gerrit
|
||||||
|
team called PROJECTNAME-unmaintained-core to handle all work on that
|
||||||
|
project's Unmaintained branches. This group is managed by the PTL or the
|
||||||
|
Unmaintained branch liaison if there is one. The group is created by
|
||||||
|
proposing an appropriate set of permissions to the project's Gerrit ACLs
|
||||||
|
in the ``openstack/project-config`` repository. See
|
||||||
|
https://review.opendev.org/c/openstack/project-config/+/902796
|
||||||
|
for an example.
|
||||||
|
|
||||||
|
|
||||||
Review guidelines
|
Review guidelines
|
||||||
=================
|
=================
|
||||||
|
|
Loading…
Reference in New Issue