 ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price <allison@openinfra.dev> wrote ----
Hi Slawek and Gmann, 

Thank you for raising the points about the OpenStack release naming process. 

On Apr 29, 2022, at 10:05 AM, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:

---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski <skaplons@redhat.com> wrote ----
Hi,

During the last PTG in April 2022 in the TC meeting we were discussing our release naming policy [1].
It seems that choosing appropriate name for every releases is very hard and time consuming. There is many factors which needs to be taken into consideration there like legal but also meaning of the chosen name in many different languages.

Adding more detail on why TC is thinking to drop the release name and keep only number (slawek
will add these in review also as histiry to know)

Why we dropped the release name:
* Problem with release name:

** We are a wider community with many international communities, developers, and cultures and choosing a perfect name satisfying all of them is not possible.
** We as individuals also have some problems with a few names which might be due to emotions, political, or historical. And filtering them out is not possible.
** Name after election need trademark checks from the foundation as a final step and there is always a chance that winning names are filtered out so the electorate might not be happy with that. So the process is also not perfect.
** <feel free to add more if I forgot to list>.

From a release marketing perspective, I have significant concerns going down this route. I think that not only do the names reflect whimsical aspects of the community personality, it’s also a huge marketing tool in terms of getting traction with OpenStack coverage. This helps us debunk some of the myths out there around the OpenStack community’s relevance as well as convey the innovation happening in the features that are delivered upstream. 

I don’t want to minimize the time consuming nature of the process as well as the cultural sensitivities, so I would like to better understand the steps here and what some of the concerns are in moving forward. From a Foundation perspective, we are happy to help take the processes off the TC as part of other release marketing activities that we do. 

I’d be happy to join a TC meeting or discuss this more at the Summit in Berlin, but I would like to discuss alternate ways to maintain the naming process we have in place if possible before moving forward. 

Thanks Alisson for joining the discussion. As it involve the foundation members/marketting team, I thought of keeping
the foundation ML in loop but forgot (doing now). 

I understand and we touch based the marketting perspective in PTG but not in detail. 

Main issue here is not just only the process but more of the cutural. None of the name is going to be
accepted by everyone in community and that is why we face the objection on name almost since
ussuri cycle. As you can see the reference I mentioned in ' * Tried to solve it in many ways' section, we
tried to solve the process in many ways but none of those are accepted as none of it is perfect.

One idea to keep markettitng things same is that we can keep some tag line with few words to
make release attractive and interesting. For example: "OpenStack 2023.1 - 'Secure & Stable' ". Does
that sovle the marketting need?

We wil be happy to discuss if there is new idea which can solve the mentioned issues. Feel free to
proposa the idea in TC and I can schedule a call for that.

-gmann

Allison 

* Tried to solve it in many ways:

There were a lot of proposals to solve the above issues but we could not get any agreement on either of these and live with all these issues until the Zed cycle.

** https://review.opendev.org/c/openstack/governance/+/677749
** https://review.opendev.org/c/openstack/governance/+/678046
** https://review.opendev.org/c/openstack/governance/+/677745
** https://review.opendev.org/c/openstack/governance/+/684688
** https://review.opendev.org/c/openstack/governance/+/675788
** https://review.opendev.org/c/openstack/governance/+/687764
** https://review.opendev.org/c/openstack/governance/+/677827
** https://review.opendev.org/c/openstack/governance/+/677748
** https://review.opendev.org/c/openstack/governance/+/677747
** https://review.opendev.org/c/openstack/governance/+/677746

-gmann

Finally we decided that now, after Zed release, when we will go all round through alphabet it is very good time to change this policy and use only numeric version with "year"."release in the year". It is proposed in [2].
This is also good timing for such change because in the same release we are going to start our "Tick Tock" release cadence which means that every Tick release will be release with .1 (like 2023.1, 2024.1, etc.) and every Tock release will be one with .2 (2023.2, 2024.2, etc.).

[1] https://etherpad.opendev.org/p/tc-zed-ptg#L265
[2] https://review.opendev.org/c/openstack/governance/+/839897

-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat

Foundation mailing list
Foundation@lists.openinfra.dev
http://lists.openinfra.dev/cgi-bin/mailman/listinfo/foundation