Unmaintained status replaces Extended Maintenance

This resolution heavily revises [1] based on
feedback from the July 11, 2023 TC meeting.

1. EM is rename to Unmaintained.
2. Branch deletion and creation under unmaintained/.
3. New Gerrit group responsible for the branch.
4. Mention of TC maintaining a checklist and process.

[1]. https://review.opendev.org/c/openstack/governance/+/887966

Change-Id: I72ac1eab3c6b1b55b4f2bc017d5befaaee138f5f

resolutions/20230724-unmaintained-branches.rst

@@ -0,0 +1,101 @@
+=============================================================
+ 2023-07-24 Unmaintained status replaces Extended Maintenance
+=============================================================
+
+Motivation
+----------
+
+In "2018-03-01 Extended maintenance for stable branches"[0] the OpenStack
+Technical Committee specified a new process for transitioning branches to
+end-of-life, allowing for a phase called extended maintenance where these
+branches are still open to receive backports, but without receiving
+official releases.
+
+Recent discussions in the mailing list[1], forum[2], and in TC meetings
+highlighted that:
+
+- The reality of most current EM branches is that they are generally not
+  maintained and may not receive security or bug fixes, or are in
+  a state of not being able to merge those fixes if proposed.
+- There is a false expectation from users and operators that these branches
+  are in a state of maintenance from the project team and receiving the above.
+- Project teams have felt a responsibility themselves to attempt to maintain
+  these branches due to the above expectation, in the absence of external
+  actors (operators, users, vendors, etc.)
+- These branches are taking attention and resources away from maintained
+  branches and new development.
+- There are no clear processes for transitioning a branch from EM to EOL, and
+  due to the process being manual, the interdependencies in testing between
+  projects, and the burden and goodwill required to transition a project from
+  EM to EOL, only 3 branches have done so in the 5 years since the introduction
+  of the policy.
+- There are currently 7 extended maintenance branches and this is starting
+  to also affect the good operation of the QA infrastructure.
+
+Goals
+-----
+
+This resolution acknowledges that
+
+- We need better communication with regard to the status of these branches,
+  specifically, that it is not (and has not been) the responsibility of the
+  project's core team to maintain them. In other words, it is not the
+  responsibility of each project's core team to review, approve, or merge
+  changes, or to keep the CI gates running on these branches.
+- There is still value and desire in creating a space for collaboration to
+  backport fixes beyond just the officially maintained releases.
+- There is a need for a clear step-by-step process when transitioning a branch
+  through these phases.
+
+This resolution therefore attempts to preserve the ability for backports to be
+proposed and merged to unmaintained branches, while improving communication
+around the responsibilities and defining clearer processes.
+
+Unmaintained branches
+---------------------
+
+- The phase of Extended Maintenance for a branch is renamed to Unmaintained.
+- Only SLURP releases are eligible for having an Unmaintained branch.
+- After a branch is no longer officially maintained, the branch is deleted and
+  a new branch is created under unmaintained/<branch_name>, for example,
+  unmaintained/train.
+- A group in Gerrit called "<project>-unmaintained-core", for example,
+  "keystone-unmaintained-core", will have +2/+W on these branches. This group
+  may be bootstrapped with or include the "<project>-stable-maint" group, but
+  membership is separate from that group.
+- The PTL, or a new Unmaintained branch liaison assigned by the PTL, makes
+  group membership decisions for "<project>-unmaintained-core".
+- 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.
+- By default, only the latest eligible Unmaintained branch is kept. When a new
+  branch is eligible, the Unmaintained branch liaison must opt-in to keep all
+  previous branches active.
+- The PTL or Unmaintained branch liaison are allowed to delete an Unmaintained
+  branch early, before its scheduled branch deletion.
+- The CI for all branches must be in good standing at the time of opt-in.
+  At a minimum this needs to contain all integrated jobs, unit tests, pep8,
+  and functional testing.
+  However, as this is a best-effort CI and to preserve resources, Unmaintained
+  branches will include periodic jobs of no higher than monthly frequency.
+- The TC will maintain and document the full steps and guidelines for
+  transitioning from maintained to unmaintained, and for the eventual branch
+  deletion.
+
+Transition
+----------
+
+The current Extended Maintenance branches are not SLURP releases and wouldn't
+be eligible for Unmaintained branches with the guidelines above.
+The first SLURP release is 2023.1.
+
+- Until the first SLURP release ends its maintained phase, all current branches
+  are eligible for Unmaintained.
+- The last 3 active Extended Maintenance branches are automatically
+  transitioned to Unmaintained branches.
+- The unmaintained branch liaison needs to opt-in to keep more than 3 branches
+  (instead of 1 for SLURP) and the guidelines for opt-in described above apply.
+
+[0]. https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
+[1]. https://lists.openstack.org/pipermail/openstack-discuss/2023-June/033980.html
+[2]. https://etherpad.opendev.org/p/vancouver-2023-em

resolutions/index.rst

@@ -7,6 +7,16 @@
 When a motion does not result in a change in a reference doc, it can
 be expressed as a resolution.
 
+2023
+====
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+   :reversed:
+
+   2023*
+
 2022
 ====