From sunny at openstack.org Wed Apr 6 13:00:00 2022 From: sunny at openstack.org (Sunny Cai) Date: Wed, 6 Apr 2022 06:00:00 -0700 Subject: [OpenInfra Foundation] What to Expect at the OpenInfra Summit Berlin - Hybrid & Private Cloud Track References: <37a8f15c-e5f6-4c05-bddd-bcff40440d57@Spark> Message-ID: Hi everyone, This week?s OpenInfra Live episode is brought to you by the community members from?G-Research, Bloomberg LP, LINE Corp and OVHcloud. Organizations have turned to the cloud to increase operational efficiency while decreasing costs. Recent studies have shown that these same organizations are turning to hybrid cloud infrastructure powered by a mixture of open source technologies for additional flexibility around workload repatriation. Within production hybrid clouds, OpenInfra technologies provide container security, edge nodes, CI/CD, secure private clouds and the largest footprint of public cloud data centers in the world. Tune into this episode and learn about what private & hybrid cloud sessions will be featured at the OpenInfra Summit Berlin, Germany on June 7-9, 2022! Episode:?What to Expect at the OpenInfra Summit Berlin - Hybrid & Private Cloud Track Date and time:?April 7 at 1400 UTC (9am CT) You can watch us live on any of the platforms below: YouTube:?https://www.youtube.com/watch?v=sIyAxZom5Hg LinkedIn:?https://www.linkedin.com/video/event/urn:li:ugcPost:6916850834005770240/ Facebook:?https://www.facebook.com/104139126308032/posts/4987319704656592/ Host:?Mark Collier, COO at the OpenInfra Foundation Speakers: ? Ross Martyn, Cloud Engineer at G-Research ? Tyler Stachecki, Cloud Infrastructure Engineer at Bloomberg LP ? Reedip Banerjee, Cloud DevOps Engineer at LINE Corp ? Yushiro Furukawa, Senior Software Engineer at LINE Corp ? Dawid Deja, Technical Lead at OVHcloud Have an idea for a future episode? Share it now at?ideas.openinfra.live. Thanks, Sunny Cai OpenInfra Foundation Marketing & Community -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison at lohutok.net Fri Apr 15 18:53:44 2022 From: allison at lohutok.net (Allison Randal) Date: Fri, 15 Apr 2022 14:53:44 -0400 Subject: [OpenInfra Foundation] OpenInfra Board Meeting, 26 Apr 2022 at 2100 UTC Message-ID: <2554acc3-2ffb-e662-142d-f573860115f1@lohutok.net> Foundation members, The next OpenInfra board meeting is April 26th. In addition to regular updates for the board, committees, and working groups, we will hold an informal brainstorming session to plan discussion topics for the Berlin F2F board meeting in June. Meeting date: April 26th, 2022 Time: 2100-2300 UTC / 2pm-4pm US Pacific Video conference/dial-in information: on agenda page Agenda: http://board.openinfra.dev/meetings/2022-04-26 Thanks, Allison From sunny at openstack.org Wed Apr 27 20:33:14 2022 From: sunny at openstack.org (Sunny Cai) Date: Wed, 27 Apr 2022 13:33:14 -0700 Subject: [OpenInfra Foundation] OpenInfra Live: Composable Infrastructure and the Future of Data Center References: Message-ID: <93b72aaa-4c84-41db-bb53-672f85722bb8@Spark> Hi everyone, This week?s OpenInfra Live episode is brought to you by the OpenInfra Foundation members from?Canonical, Intel, Fungible and Open Compute Project. The advent of composable hardware introduces complexity and choice that heretofore hasn?t existed in the data center. How does today?s open infrastructure software adapt and what does the future of the data center look like in this new world? Join us to talk about the intersection of software-defined DPUs, IPUs, GPUs, SmartNICs, and all of the open infrastructure software that sits on top. Episode:?Composable Infrastructure and the Future of Data Centers Date and time:?April 28 at 1400 UTC (9am CT) You can watch us live on any of the platforms below: YouTube:?https://www.youtube.com/watch?v=CwudpYeQHj0 LinkedIn:?https://www.linkedin.com/video/event/urn:li:ugcPost:6922961286364348416/ Facebook:?https://www.facebook.com/104139126308032/posts/5030445067010722/ Host:?Jonathan Bryce, Executive Director at the OpenInfra Foundation Speakers: ? George Tchaparian ? CEO of OCP ? Pradeep Sindhu ? Co-founder and Chief Development Officer at Fungible ? Dan Daly ? Senior Principal Engineer at Intel ? Dmitrii Shcherbakov ? Senior Engineer at Canonical Have an idea for a future episode? Share it now at?ideas.openinfra.live. Thanks, Sunny Cai OpenInfra Foundation Marketing & Community -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Apr 29 15:53:02 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 29 Apr 2022 10:53:02 -0500 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> Message-ID: <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price 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 wrote: > > > > ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. > > ** . > > 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 > >> > > > > > From kurt at garloff.de Fri Apr 29 17:03:47 2022 From: kurt at garloff.de (Kurt Garloff) Date: Fri, 29 Apr 2022 19:03:47 +0200 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> Message-ID: <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> 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. Replacing well rememberable names with sterile numbers is definitely a step backwards in perception. Just my 0.02?. -- Kurt Am 29. April 2022 17:53:02 MESZ schrieb Ghanshyam Mann : > ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price 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 wrote: > > > > > > ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. > > > ** . > > > > 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 , Cologne, Germany (Sent from Mobile with K9.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at garloff.de Fri Apr 29 17:03:47 2022 From: kurt at garloff.de (Kurt Garloff) Date: Fri, 29 Apr 2022 19:03:47 +0200 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> Message-ID: <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> 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. Replacing well rememberable names with sterile numbers is definitely a step backwards in perception. Just my 0.02?. -- Kurt Am 29. April 2022 17:53:02 MESZ schrieb Ghanshyam Mann : > ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price 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 wrote: > > > > > > ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. > > > ** . > > > > 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 , Cologne, Germany (Sent from Mobile with K9.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Apr 29 17:35:31 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 29 Apr 2022 12:35:31 -0500 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> Message-ID: <18076645fad.c8ca1e22409208.778705174696178878@ghanshyammann.com> ---- On Fri, 29 Apr 2022 12:03:47 -0500 Kurt Garloff 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. [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 : ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price 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 wrote: > > ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. > ** . > > 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 , Cologne, Germany > (Sent from Mobile with K9.) From gmann at ghanshyammann.com Fri Apr 29 17:35:31 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 29 Apr 2022 12:35:31 -0500 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> Message-ID: <18076645fad.c8ca1e22409208.778705174696178878@ghanshyammann.com> ---- On Fri, 29 Apr 2022 12:03:47 -0500 Kurt Garloff 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. [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 : ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price 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 wrote: > > ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. > ** . > > 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 , Cologne, Germany > (Sent from Mobile with K9.) From allison at openinfra.dev Fri Apr 29 18:18:33 2022 From: allison at openinfra.dev (Allison Price) Date: Fri, 29 Apr 2022 13:18:33 -0500 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <18076645fad.c8ca1e22409208.778705174696178878@ghanshyammann.com> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> <18076645fad.c8ca1e22409208.778705174696178878@ghanshyammann.com> Message-ID: <1E9F233D-46CE-4369-970D-0532B0EE981D@openinfra.dev> > On Apr 29, 2022, at 12:35 PM, Ghanshyam Mann wrote: > > ---- On Fri, 29 Apr 2022 12:03:47 -0500 Kurt Garloff 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. I?ll put time on the next TC meeting agenda to join and discuss this as an option, but I it?s something we are happy to resource. > >> >> 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. > > [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 : ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price 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 wrote: >> >> ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. >> ** . >> >> 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 , Cologne, Germany >> (Sent from Mobile with K9.) > From allison at openinfra.dev Fri Apr 29 18:18:33 2022 From: allison at openinfra.dev (Allison Price) Date: Fri, 29 Apr 2022 13:18:33 -0500 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <18076645fad.c8ca1e22409208.778705174696178878@ghanshyammann.com> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> <18076645fad.c8ca1e22409208.778705174696178878@ghanshyammann.com> Message-ID: <1E9F233D-46CE-4369-970D-0532B0EE981D@openinfra.dev> > On Apr 29, 2022, at 12:35 PM, Ghanshyam Mann wrote: > > ---- On Fri, 29 Apr 2022 12:03:47 -0500 Kurt Garloff 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. I?ll put time on the next TC meeting agenda to join and discuss this as an option, but I it?s something we are happy to resource. > >> >> 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. > > [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 : ---- On Fri, 29 Apr 2022 10:15:27 -0500 Allison Price 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 wrote: >> >> ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. >> ** . >> >> 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 , Cologne, Germany >> (Sent from Mobile with K9.) > From alex.kavanagh at canonical.com Fri Apr 29 19:23:55 2022 From: alex.kavanagh at canonical.com (Alex Kavanagh) Date: Fri, 29 Apr 2022 20:23:55 +0100 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> Message-ID: On Fri, Apr 29, 2022 at 6:24 PM Kurt Garloff 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. > > Replacing well rememberable names with sterile numbers is definitely a > step backwards in perception. > I tend to agree. I, also, can remember most of the names; they provide a more tangible feel for the project. Cheers Alex. > 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 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 wrote: >>>> >>>> ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. >>>> ** . >>>> >>> >>> 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 , Cologne, Germany > (Sent from Mobile with K9.) > -- Alex Kavanagh - Software Engineer OpenStack Engineering - Data Centre Development - Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kavanagh at canonical.com Fri Apr 29 19:23:55 2022 From: alex.kavanagh at canonical.com (Alex Kavanagh) Date: Fri, 29 Apr 2022 20:23:55 +0100 Subject: [OpenInfra Foundation] [all][tc] Change OpenStack release naming policy proposal In-Reply-To: <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> References: <2175937.irdbgypaU6@p1> <18075db6e21.118543125401989.8208677652226278753@ghanshyammann.com> <088599E0-4F95-4467-900A-5041704BD031@openinfra.dev> <18076068c94.f090875e405065.8322699810706317962@ghanshyammann.com> <52AED2E2-E10F-463B-A06D-D219B246D980@garloff.de> Message-ID: On Fri, Apr 29, 2022 at 6:24 PM Kurt Garloff 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. > > Replacing well rememberable names with sterile numbers is definitely a > step backwards in perception. > I tend to agree. I, also, can remember most of the names; they provide a more tangible feel for the project. Cheers Alex. > 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 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 wrote: >>>> >>>> ---- On Fri, 29 Apr 2022 09:55:52 -0500 Slawek Kaplonski 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. >>>> ** . >>>> >>> >>> 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 , Cologne, Germany > (Sent from Mobile with K9.) > -- Alex Kavanagh - Software Engineer OpenStack Engineering - Data Centre Development - Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: