Open Stack

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 at ghanshyammann.com> wrote:
> 
> ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski <skaplons at 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. 

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
>> 
>