Open Stack

 ---- On Fri, 29 Apr 2022 12:35:31 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Fri, 29 Apr 2022 12:03:47 -0500 Kurt Garloff <kurt at garloff.de> wrote ----
 >  > Hi,
 >  > 
 >  > I see a tendency in western societies that no decisions are ever taken out of fear someone could be offended or even litigate.
 >  > While it's very reasonable to be careful to avoid offenses, we must not take it to the extreme and allow it to paralyze us by requiring no one ever objects, IMVHO. 100% happiness is too high a bar.
 >  > 
 >  > I would hope that the offer from the foundation staff to help with the name vetting process and take off load from the TC is helpful here.
 > 
 > Definatly that an option and we will be happy to do that.
 > 
 >  > 
 >  > Replacing well rememberable names with sterile numbers is definitely a step backwards in perception.
 > 
 > Well, it depends. For marketting yes names are great to remember and publish but from tehnical perspective especially
 > while upgrade they are hard to know which year these releses were released. And when we will have tick-tock release
 > model[1] number are more useful to know by operators what which one is tick release and which one is tock. With name
 > only it is not best way to find.
 > 
 > So both have its pros and cons.

NOTE: It seems keeping both ML 'openstck-discuss' and 'foundation' is not the right way as per the ML Etiquette[1] even I am
sure that restrict the communication for topic targetting more than one ML or asking more people to join other ML for a single
topic. 

So let's keep this thread discussion in openstack-dicuss ML only and anyone from other ML interested in this tiopic can join in
openstack-discuss ML. Sorry for the confusion.

-- foundation ML.

[1] https://wiki.openstack.org/wiki/MailingListEtiquette#Avoid_cross-posting

-gmann

 > 
 > [1] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html
 > 
 > -gmann 
 > 
 >  > 
 >  > Just my 0.02€.
 >  > -- Kurt
 >  > 
 >  > Am 29. April 2022 17:53:02 MESZ schrieb Ghanshyam Mann <gmann at ghanshyammann.com>: ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price <allison at 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 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. 
 >  > 
 >  > 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 at lists.openinfra.dev
 >  > http://lists.openinfra.dev/cgi-bin/mailman/listinfo/foundation
 >  > -- 
 >  > Kurt Garloff <kurt at garloff.de>, Cologne, Germany
 >  > (Sent from Mobile with K9.)
 > 
 >