Documenting the OpenStack release new identification process

After the discussion in ML thread[1], gerrit[2], Foundation
staff joined in TC meeting and we all agreed to give the release
name handling to Foundation and TC will not be involved in that[3].

Release name will be used for marketing purpose and release tooling
but we will use the release number as a primary identifier in the
OpenStack development cycle. TC had another call[4] to discuss about
the details of where to use releae name and number and passed the
resolution
- https://review.opendev.org/c/openstack/governance/+/843214

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028354.html
[2] https://review.opendev.org/c/openstack/governance/+/839897
[3] https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-12-15.00.log.html#l-245
[4] https://etherpad.opendev.org/p/openstack-release-identification-schema

Change-Id: Ibeb66662e7b71c3b7b1c1acee3bfccfcca11e544

reference/release-naming.rst

@@ -13,7 +13,7 @@ Example:
 * OpenStack 2023.1 Axxxx
 
 Where "2023" is the year of the release, "1" represents the first release
-of the year and "Axxxx" is the release name following the release name rules.
+of the year and "Axxxx" is the release name.
 
 Other examples:
 
@@ -24,64 +24,44 @@ With this release identification schema we get an easy and sustainable
 approach to identify different OpenStack releases without dealing with the
 ambiguity of the release name and alphabet iteration.
 
-The release identification schema doesn't replace the release name.
+The OpenStack Technical Committee has passed a :doc:`resolution
-It's just an unambiguous way to identify OpenStack releases.
+<../resolutions/20220524-release-identification-process>` for the release
+identification process. The release number will be used as the primary
+identifier in the development cycle but the release name will also be used
+in some places.
+
+* Stable branches: Use release number for stable branch name.
+  Example: stable/2023.1
+
+* Spec repo or any other directory structure: Use release number which is more
+  aligned with what stable branches are going to use.
+
+* Testing tools: Use release number which is more aligned with what stable
+  branches are going to use.
+
+* Release page/tooling/milestone name: The release team can choose either to
+  continue using the release name or use number for release tooling and
+  milestone name.
 
 Release Name
 ------------
 
-Each OpenStack development cycle has a code-name that is
+We will continue with the release name but mainly for marketing usage.
-proposed and chosen by the community.  This name is frequently used in
-preference to version numbers to refer to the release at the end of
-the cycle.  The process of choosing the name should be an enjoyable
-activity for the community to mark the software development cycle, and
-the name itself should be fun to use.
 
-Because the name will become associated with OpenStack, and a
+* OpenStack release names will be handled by the staff of the OpenInfra
-particular release, the process should consider potential issues of
+  Foundation.
-trademark.
 
-Release Naming Process
+* Foundation staff will define the naming criteria and process but make sure
-----------------------
+  they satisfy the OpenStack release team's tooling requirements.
 
-#. Anyone may propose a name that matches the `Release Name
+* The OpenStack release team PTL sign-off is needed on naming criteria defined
-   Criteria`_.  Proposed names should be added to a page on the
+  by the Foundation staff.
-   OpenStack wiki.
 
-#. A Condorcet election is held to rank the names. The electorate will be
+* The OpenStack Technical Committee will not be involved in the process,
-   Technical Committee, and the poll should  be run in a manner that allows
+  the release team will directly coordinate with the foundation staff.
-   members of the community to see what each TC member voted for.
 
-#. The Foundation will perform a trademark check on the winning name.
+Release Name Selection History
-   If there is a trademark conflict, then the Foundation will proceed
+------------------------------
-   down the ranked list of Condorcet results until a name without a
-   trademark conflict is found.  This will be the selected name.
-
-
-Release Name Criteria
----------------------
-
-The following rules are designed to provide some consistency in the
-pattern used to select release names, provide a fun challenge in
-finding names that meet the criteria, and prevent unwieldy names from
-being chosen.
-
-#. Each release name must start with the letter of the ISO basic Latin
-   alphabet following the initial letter of the previous release,
-   starting with the initial release of "Austin".  After "Z", the next
-   name should start with "A" again.
-
-#. A release name can't be repeated between different iterations of the
-   alphabet.
-
-#. The name must be composed only of the 26 characters of the ISO
-   basic Latin alphabet.  Names which can be transliterated into this
-   character set are also acceptable.
-
-#. The name must be a single word with a maximum length of 10 characters.
-
-Polls
------
 
 =======  ==============  ================  ==========  ==========  ==================
 Release  Coordinator     Nominations Open  Poll Open   Poll Close  Geographic Region
@@ -102,6 +82,9 @@ Y_       Ghanshyam Mann  2021-05-13        2021-06-10  2021-06-17  N/A
 Z_       Ghanshyam Mann  2022-01-11        2022-01-25  2022-02-01  N/A
 =======  ==============  ================  ==========  ==========  ==================
 
+The Zed release is the last release for which the OpenStack Technical Committee
+was involved in the selection of the release name.
+
 .. [*] Starting with the W release, the naming criteria changed from referring
    to the physical or human geography of the region encompassing the location
    of the OpenStack Summit, to any name proposed by the community that starts