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

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 <gmann@ghanshyammann.com>:

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

-- Kurt Garloff <kurt@garloff.de>, Cologne, Germany (Sent from Mobile with K9.)

---- On Fri, 29 Apr 2022 12:35:31 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----

---- On Fri, 29 Apr 2022 12:03:47 -0500 Kurt Garloff <kurt@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-adj...

-gmann

...

Just my 0.02€. -- Kurt

Am 29. April 2022 17:53:02 MESZ schrieb Ghanshyam Mann <gmann@ghanshyammann.com>: ---- 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 -- Kurt Garloff <kurt@garloff.de>, Cologne, Germany (Sent from Mobile with K9.)

---- On Fri, 29 Apr 2022 13:18:33 -0500 Allison Price <allison@openinfra.dev> wrote ----

...

On Apr 29, 2022, at 12:35 PM, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:

---- On Fri, 29 Apr 2022 12:03:47 -0500 Kurt Garloff <kurt@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.

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.

Thanks Allison, I will say to add it in 12th May meeting and meanwhile we will get more feedback on ML discussion. Let me know of that works for you. -gmann

...

...

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

-gmann

...

Just my 0.02€. -- Kurt

Am 29. April 2022 17:53:02 MESZ schrieb Ghanshyam Mann <gmann@ghanshyammann.com>: ---- 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 -- Kurt Garloff <kurt@garloff.de>, Cologne, Germany (Sent from Mobile with K9.)

---- On Mon, 02 May 2022 10:49:09 -0500 Thomas Goirand <zigo@debian.org> wrote ----

On 4/29/22 19:35, Ghanshyam Mann wrote:

...

[...] from tehnical perspective especially while upgrade they are hard to know which year these releses were released.

Excuse my words (I'm being direct, hopefully not offensive), but I'm calling "bullshit" on this one! :) Just read this page and you know:

Sorry, Thomas but being direct or justifying the disagreement is a separate thing from using such words, I do not find these appropriate. My humble request is to avoid these, please.

https://releases.openstack.org/

Yes, this page has all information but that is what my point was, you need to look into the release page to get those details then just getting that information from release name/number.

...

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.

Except that the above page could be modified to tell tick or tock...

Yes, that is the plan but we are checking the legal things also in case any issue to use 'tick', 'tock' word.

Also, hopefully, at some point we will forget about the "tock" release and decide it's ok to upgrade from 4 releases ago (how can you tell we're not going to do that one day?).

Anything is possible in the future :) and nobody knows that. But on a serious note, yes there might be a chance that tock can go away or tick timeline can be increased. That is what we will see based on feedback and users' need. But as per the current plan, there are no such things planned and we will continue with tick, tock way. -gmann

Cheers,

Thomas Goirand (zigo)

Hi, I replied in the patch, but I also would like to express my opinion in this thread. Release names can be problematic as described in this proposal. https://review.opendev.org/c/openstack/governance/+/839897 However, I still think that the release name is important for the community. It’s part of the OpenStack culture! Is something that we have since the release “A” for “Austin”. I never saw anyone mentioning that they are still running Nova with the release “2011.3” and need to upgrade. Instead the community mentions the release name, “Diablo” (for example...) Having said that, I also believe it’s important to have a clear release identification schema without the ambiguity of the alphabet iteration. In my opinion both should coexist. Belmiro On Mon, May 2, 2022 at 8:01 PM Thomas Goirand <zigo@debian.org> wrote:

...

---- On Mon, 02 May 2022 10:49:09 -0500 Thomas Goirand < zigo@debian.org> wrote ----

...

On 4/29/22 19:35, Ghanshyam Mann wrote:

...

[...] from tehnical perspective especially while upgrade they are hard to know which year these releses were released.

Excuse my words (I'm being direct, hopefully not offensive), but I'm calling "bullshit" on this one! :) Just read this page and you know:

Sorry, Thomas but being direct or justifying the disagreement is a separate thing from using such words, I do not find these appropriate. My humble request is to avoid

On 5/2/22 18:14, Ghanshyam Mann wrote: these, please.

Ok, sorry... :/

...

Yes, this page has all information but that is what my point was, you need to look into the release page to get those details then just getting that information from release name/number.

The same way, you need to remember that 202x.1 is tick, and 202x.2 is tock. Oh, or is it the other way around?!? I actually think it is, with current plan...

Cheers,

Thomas Goirand (zigo)

On Fri, Apr 29, 2022 at 6:24 PM Kurt Garloff <kurt@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.

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@ghanshyammann.com>:

...

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

--

Kurt Garloff <kurt@garloff.de>, Cologne, Germany (Sent from Mobile with K9.)

-- Alex Kavanagh - Software Engineer OpenStack Engineering - Data Centre Development - Canonical Ltd

On 2022-04-29 17:43:25 +0200 (+0200), Marcin Juszkiewicz wrote: [...]

Also suggestion: drop tick/tock from naming documentation please. I never remember which is major and which is minor.

This is a good point. From an internationalization perspective, the choice of wording could be especially confusing as it's an analogy for English onomatopoeia related to mechanical clocks. I doubt it would translate well (if at all). In retrospect, adjusting the terminology to make 2023.1 the "primary" release of 2023, with 2023.2 as the "secondary" release of that year, makes it a bit more clear as to their relationship to one another. We can say that consumers are able to upgrade directly from one primary release to another, skipping secondary releases. -- Jeremy Stanley

---- On Fri, 29 Apr 2022 14:07:15 -0500 Dan Smith <dms@danplanet.com> wrote ----

...

...

Also suggestion: drop tick/tock from naming documentation please. I never remember which is major and which is minor.

This is a good point. From an internationalization perspective, the choice of wording could be especially confusing as it's an analogy for English onomatopoeia related to mechanical clocks. I doubt it would translate well (if at all).

I don't think there's any implication that one or the other is major or minor. I certainly didn't think the word "tick" meant anything more major or important than "tock". I chose "tick" as the slow-path one simply because I think it makes sense to start the cycle on a slow path release. Unless we choose "major and minor" or "long and short" or "stable and unstable" (the latter of which is already taken and also not correct anyway), I think people will have to learn which is which regardless.

...

In retrospect, adjusting the terminology to make 2023.1 the "primary" release of 2023, with 2023.2 as the "secondary" release of that year, makes it a bit more clear as to their relationship to one another. We can say that consumers are able to upgrade directly from one primary release to another, skipping secondary releases.

I also don't think "primary and secondary" are appropriate because they have other connotations which also don't apply here. We decided that "the release after Zed" would be the first in this cycle, and the version of that is fixed based on when it is in the year. I don't think we should tie the position of that release in the year to the notion of the slow or fast cycle nature of them. Especially if we decide to change that cadence to some other pattern in the future.

I agree with Dan, we discussed it to name it differnetly but everything came up like naming one release (tick currently) more stable and other one less stable. Like Major-minor or Primary-Secondary does the same. Both the release are same stable and no change in feature development, bug fixes (like tick will not implement more feature then tock or so). So we need to clearly avoid any name which will convey them stable, less-stable or this is main and that is not-main.

I chose "tick and tock" simply because there's precedent in the industry and that's all. I think the terminology we choose is not going to be fully intuitive and culturally appropriate for everyone on the planet, much like release names. We've already documented and discussed these as "tick and tock" and changing now/again will also bring its own confusion.

I agree tick-tock might not be best names/tag or all people are familier with and I can give 100 of names to us in alternate to tick-tock but as we have already documented about it and discussed a lot in PTG so let's keep them as it is. Adding new names will confuse more people than making it more clear. -gmann

See, isn't this naming stuff fun?

--Dan

I'm highly disappointed in this 'decision', and would like for you to reconsider. I see the reasons you cite, but I feel like we're throwing the baby out with the bathwater here. Disagreements need not be feared, why not allow them to be aired publicly? That's a tenet of this open community. Allow names to be downvoted with reason during the proposal phase, and they'll organically fall-off from favor.

We had this problem when the entire community chose release names too. Objections to nominations are solicited, and need not be secret. Even this cycle there were publicly-aired complaints about the release name on this very list, despite no objections being raised during the nomination period. I seriously thought that "Zed" would be the least possibly offensive name, given that it is literally the name of the letter in much of the world. There were *two* completely separate and serious objections to the name from multiple people each.

Release names have always been a bonding factor. I've been happy to drum up contributor morale with our release names and the stories/anecdotes behind them.

Agreed that they were in the past, and that they should be. It doesn't feel that way anymore.

I do believe our current release naming process is a step out of the TC's perceived charter. There are many technical challenges that the TC is tackling, and coordinating a vote/slugfest about names isn't as important as those. As Allison suggests, we could seek help from the foundation to run the community voting and vetting for the release naming process - and expect the same level of transparency as the 4 opens that the OpenStack community espouses.

I'm totally fine with the foundation taking it over completely if that's what they want to do. My reasoning for wanting to do away with names is primarily that it has become more labor-intensive than beneficial for the TC, in my opinion. I have other lesser reasons too, but they're not as important. I'm sure everyone dutifully clicked on all of the links gmann provided, but let me just make sure you see this one: https://review.opendev.org/c/openstack/governance/+/677747 "Let the foundation do it" didn't even make it to the final round of consideration the last time the process was considered :) --Dan

---- On Fri, 29 Apr 2022 14:11:12 -0500 Goutham Pacha Ravi <gouthampravi@gmail.com> wrote ----

On Fri, Apr 29, 2022 at 8:36 PM 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.

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

Beloved TC,

I'm highly disappointed in this 'decision', and would like for you to reconsider. I see the reasons you cite, but I feel like we're throwing the baby out with the bathwater here. Disagreements need not be feared, why not allow them to be aired publicly? That's a tenet of this open community. Allow names to be downvoted with reason during the proposal phase, and they'll organically fall-off from favor.

Release names have always been a bonding factor. I've been happy to drum up contributor morale with our release names and the stories/anecdotes behind them. Release naming will not hurt/help the tick-tock release IMHO. We can append the release number to the name, and call it a day if you want.

I agree with the disagrement ratio and that should not stop us doing the things. But here we need to understand what type of disagrement we have and on what. Most of the disagrement were cutural or historical where people has shown it emotinally. And I personally as well as a TC or communitiy member does not feel goot to ignore them or give them any reasoning not to listen them (because I do not have any reasoning on these cultural/historical disagrement). Zed cycle was one good example of such thing when it was brought up in TC channel about war thing[1] and asked about change the Zed name. I will be happy to know what is best solution for this. 1. Change Zed name: it involve lot of technical work and communciation too. If yes then let's do this now. 2. Do not listen to these emotional request to change name: We did this at the end and I do not feel ok to do that. At least I do not want to ignore such request in future. Those are main reason we in TC decided to remvoe the name as they are culturally, emotionally tied. That is main reason of droping those not any techncial or work wise issue. [1] https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2022-03... -gmann

I do believe our current release naming process is a step out of the TC's perceived charter. There are many technical challenges that the TC is tackling, and coordinating a vote/slugfest about names isn't as important as those. As Allison suggests, we could seek help from the foundation to run the community voting and vetting for the release naming process - and expect the same level of transparency as the 4 opens that the OpenStack community espouses.

Yes we will offcourse open to that but at the same time we will be waiting for the foudnation proposal to sovle such issue irespective of who is doing name selection. So let's wait for that. -gmann

...

[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

---- On Fri, 13 May 2022 20:43:57 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----

Hello Everyone,

Writing on the top for quick reading as we have a consensus on this.

In today's TC meeting [3], we discussed this topic with Foundation staff and we all agreed to give the release name process handling to Foundation. TC will not be involved in the process. The release name will be mainly used for marketing purposes and we will use the release number as the primary identifier in our release scheduling, automated processes, directory structure etc.

I have proposed the patch to document it in the TC release naming process.

- https://review.opendev.org/c/openstack/governance/+/841800

As the next step, we will have a voice call to figure out how to use the number/name in our development cycle/tooling. Meeting details are below: * When Tue May 24, 2022 9am – 10am Pacific Time (16:00 - 17:00 UTC) * Joining info Join with Google Meet = meet.google.com/gwi-cphb-rya * Join by phone: (US) +1 563-447-5079 (PIN: 263292866) -gmann

[1] https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-12-15.00.log.html#l...

-gmann

---- On Fri, 29 Apr 2022 14:47:31 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----

...

---- On Fri, 29 Apr 2022 14:11:12 -0500 Goutham Pacha Ravi <gouthampravi@gmail.com> wrote ----

...

On Fri, Apr 29, 2022 at 8:36 PM 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.

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

Beloved TC,

I'm highly disappointed in this 'decision', and would like for you to reconsider. I see the reasons you cite, but I feel like we're throwing the baby out with the bathwater here. Disagreements need not be feared, why not allow them to be aired publicly? That's a tenet of this open community. Allow names to be downvoted with reason during the proposal phase, and they'll organically fall-off from favor.

Release names have always been a bonding factor. I've been happy to drum up contributor morale with our release names and the stories/anecdotes behind them. Release naming will not hurt/help the tick-tock release IMHO. We can append the release number to the name, and call it a day if you want.

I agree with the disagrement ratio and that should not stop us doing the things. But here we need to understand what type of disagrement we have and on what. Most of the disagrement were cutural or historical where people has shown it emotinally. And I personally as well as a TC or communitiy member does not feel goot to ignore them or give them any reasoning not to listen them (because I do not have any reasoning on these cultural/historical disagrement).

Zed cycle was one good example of such thing when it was brought up in TC channel about war thing[1] and asked about change the Zed name. I will be happy to know what is best solution for this.

1. Change Zed name: it involve lot of technical work and communciation too. If yes then let's do this now.

2. Do not listen to these emotional request to change name: We did this at the end and I do not feel ok to do that. At least I do not want to ignore such request in future.

Those are main reason we in TC decided to remvoe the name as they are culturally, emotionally tied. That is main reason of droping those not any techncial or work wise issue.

[1] https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2022-03...

-gmann

...

I do believe our current release naming process is a step out of the TC's perceived charter. There are many technical challenges that the TC is tackling, and coordinating a vote/slugfest about names isn't as important as those. As Allison suggests, we could seek help from the foundation to run the community voting and vetting for the release naming process - and expect the same level of transparency as the 4 opens that the OpenStack community espouses.

Yes we will offcourse open to that but at the same time we will be waiting for the foudnation proposal to sovle such issue irespective of who is doing name selection. So let's wait for that.

-gmann

...

...

[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

On Fri, May 20, 2022, 7:03 PM Thomas Goirand <zigo@debian.org> wrote:

On 5/20/22 19:42, Ghanshyam Mann wrote:

...

* Joining info Join with Google Meet = meet.google.com/gwi-cphb-rya

What would it take to make everyone switch to free software? We're moving from one non-free platform (zoom) to another (google meet), even if we have Jitsi that works very well... :/

Jitsi degrades beyond 16 or so interactive users. I love it and wish it well, but it's just not there yet. If the situation has changed in recent months, great then let's take a look.

Cheers,

Thomas Goirand (zigo)

On Fri, 2022-05-20 at 23:07 -0500, Ghanshyam Mann wrote:

@zigo, If you have tried any free and stable platforms for video calls, please suggest and we will love to use that.

Hey, Here at Catalyst Cloud we use Big Blue Button -  https://bigbluebutton.org/ - which we host ourselves (on our OpenStack public cloud!). We regularly have 100 people in meetings. You can try BBB on their website, although I'm not sure what the demo service is like. I'm sure that Catalyst could host a meeting if the demo service isn't suitable. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand andrew@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |

On Sat, 2022-05-21 at 17:33 +0200, Thomas Goirand wrote:

On 5/21/22 06:07, Ghanshyam Mann wrote:

...

---- On Fri, 20 May 2022 20:56:27 -0500 Erik McCormick <emccormick@cirrusseven.com> wrote ----

...

On Fri, May 20, 2022, 7:03 PM Thomas Goirand <zigo@debian.org> wrote: On 5/20/22 19:42, Ghanshyam Mann wrote:

...

* Joining info Join with Google Meet = meet.google.com/gwi-cphb-rya

What would it take to make everyone switch to free software? We're moving from one non-free platform (zoom) to another (google meet), even if we have Jitsi that works very well... :/

Jitsi degrades beyond 16 or so interactive users. I love it and wish it well, but it's just not there yet. If the situation has changed in recent months, great then let's take a look.

Yeah, we try to use that as our first preference but it did not work as expected. In a recent usage in RBAC discussion a few weeks ago, many attendees complained about audio, joining issues or so. That is why we are using non-free tooling.

@zigo, If you have tried any free and stable platforms for video calls, please suggest and we will love to use that.

-gmann

As I understand, the point isn't to make more than 16 persons talk in the meeting. Let me know if I'm wrong.

In such case, a setup similar to Debconf (which used Jitsi for Debconf 2020 and 2021) can be used. You get just a few people in the meeting, and everyone else just listens to the broacast (ie: a regular online video in your browser or VLC). in general whe we have video meeting for thinkgs like rbac discussions we do want to allow most or all attendes to be able to talk so using vlc to have everyone else just listent would fail that requireemtn in general.

if it was a presentation sure but for a meeting that would not really be useful

The full setup is well documented [1], and we have free software ansible scripts [2]. This allows thousands of attendees, plus recording and reviewing of the videos.

I very much would love if there was some efforts put in this direction (or some similar setup, as long as it's fully free).

Hoping this helps, Cheers,

Thomas Goirand (zigo)

[1] https://video.debconf.org [2] https://salsa.debian.org/debconf-video-team

On Mon, May 23, 2022, at 8:45 AM, Ghanshyam Mann wrote:

---- On Mon, 23 May 2022 04:54:23 -0500 Sean Mooney <smooney@redhat.com> wrote ----

...

On Sat, 2022-05-21 at 17:33 +0200, Thomas Goirand wrote:

...

On 5/21/22 06:07, Ghanshyam Mann wrote:

...

---- On Fri, 20 May 2022 20:56:27 -0500 Erik McCormick <emccormick@cirrusseven.com> wrote ----

...

On Fri, May 20, 2022, 7:03 PM Thomas Goirand

<zigo@debian.org> wrote:

...

On 5/20/22 19:42, Ghanshyam Mann wrote:

...

* Joining info Join with Google Meet = meet.google.com/gwi-cphb-rya

What would it take to make everyone switch to free software? We're moving from one non-free platform (zoom) to another (google meet), even if we have Jitsi that works very well... :/

Jitsi degrades beyond 16 or so interactive users. I love it and wish it well, but it's just not there yet. If the situation has changed in recent months, great then let's take a look.

Yeah, we try to use that as our first preference but it did not work as expected. In a recent usage in RBAC discussion a few weeks ago, many attendees complained about audio, joining issues or so. That is why we are using non-free tooling.

@zigo, If you have tried any free and stable platforms for video calls, please suggest and we will love to use that.

-gmann

As I understand, the point isn't to make more than 16 persons talk in the meeting. Let me know if I'm wrong.

In such case, a setup similar to Debconf (which used Jitsi for Debconf 2020 and 2021) can be used. You get just a few people in the meeting, and everyone else just listens to the broacast (ie: a regular online video in your browser or VLC). in general whe we have video meeting for thinkgs like rbac discussions we do want to allow most or all attendes to be able to talk so using vlc to have everyone else just listent would fail that requireemtn in general.

if it was a presentation sure but for a meeting that would not really be useful

Yeah, these are more interactive meetings than presentation style. If anyone attending the the meeting I expect they will participate in the discussion sometimes or at least can/should be able to make comments when things are related to their projects/area or so.

Jitsi meet seems to scale on the client side and video seems to impact that quite a bit. What this means is the more people you have in a call and the more people streaming webcams the worse the experience. That said it does seem to work fairly well with 30-40 people if video is turned off and you rely on the paired etherpad system. It isn't perfect, but the OpenDev team uses it when we need to do calls. That said it has been a while since I was in a call that large. As for debugging why sound doesn't work as mentioned prior to the PTG one known issue is that Firefox seems to treat jitsi's webrtc as autoplayed audio which means you have to enable autoplay audio for the jitsi server or enable it globally. Other than that we are not currently aware of any issues preventing audio (or video) from working. It is always a great help if the people who have problems with tools like this can reach out so that we can help debug them. Instead we're just told it doesn't work and get no details that are actionable. The mobile clients do seem to work quite well if you need a fallback too.

-gmann

...

...

The full setup is well documented [1], and we have free software ansible scripts [2]. This allows thousands of attendees, plus recording and reviewing of the videos.

I very much would love if there was some efforts put in this direction (or some similar setup, as long as it's fully free).

Hoping this helps, Cheers,

Thomas Goirand (zigo)

[1] https://video.debconf.org [2] https://salsa.debian.org/debconf-video-team

On Tue, 2022-05-24 at 08:06 +0200, Slawek Kaplonski wrote:

Hi,

Dnia poniedziałek, 23 maja 2022 17:53:39 CEST Clark Boylan pisze:

...

On Mon, May 23, 2022, at 8:45 AM, Ghanshyam Mann wrote:

...

---- On Mon, 23 May 2022 04:54:23 -0500 Sean Mooney <smooney@redhat.com> wrote ----

...

On Sat, 2022-05-21 at 17:33 +0200, Thomas Goirand wrote:

...

On 5/21/22 06:07, Ghanshyam Mann wrote:

...

---- On Fri, 20 May 2022 20:56:27 -0500 Erik McCormick <emccormick@cirrusseven.com> wrote ---- > > On Fri, May 20, 2022, 7:03 PM Thomas Goirand <zigo@debian.org> wrote: > On 5/20/22 19:42, Ghanshyam Mann wrote: > > * Joining info Join with Google Meet = meet.google.com/gwi-cphb-rya > > What would it take to make everyone switch to free software? We're > moving from one non-free platform (zoom) to another (google meet), even > if we have Jitsi that works very well... :/ > > Jitsi degrades beyond 16 or so interactive users. I love it and wish it well, but it's just not there yet. If the situation has changed in recent months, great then let's take a look.

Yeah, we try to use that as our first preference but it did not work as expected. In a recent usage in RBAC discussion a few weeks ago, many attendees complained about audio, joining issues or so. That is why we are using non-free tooling.

@zigo, If you have tried any free and stable platforms for video calls, please suggest and we will love to use that.

-gmann

As I understand, the point isn't to make more than 16 persons talk in the meeting. Let me know if I'm wrong.

In such case, a setup similar to Debconf (which used Jitsi for Debconf 2020 and 2021) can be used. You get just a few people in the meeting, and everyone else just listens to the broacast (ie: a regular online video in your browser or VLC). in general whe we have video meeting for thinkgs like rbac discussions we do want to allow most or all attendes to be able to talk so using vlc to have everyone else just listent would fail that requireemtn in general.

if it was a presentation sure but for a meeting that would not really be useful

Yeah, these are more interactive meetings than presentation style. If anyone attending the the meeting I expect they will participate in the discussion sometimes or at least can/should be able to make comments when things are related to their projects/area or so.

Jitsi meet seems to scale on the client side and video seems to impact that quite a bit. What this means is the more people you have in a call and the more people streaming webcams the worse the experience. That said it does seem to work fairly well with 30-40 people if video is turned off and you rely on the paired etherpad system. It isn't perfect, but the OpenDev team uses it when we need to do calls. That said it has been a while since I was in a call that large.

As for debugging why sound doesn't work as mentioned prior to the PTG one known issue is that Firefox seems to treat jitsi's webrtc as autoplayed audio which means you have to enable autoplay audio for the jitsi server or enable it globally. Other than that we are not currently aware of any issues preventing audio (or video) from working. It is always a great help if the people who have problems with tools like this can reach out so that we can help debug them. Instead we're just told it doesn't work and get no details that are actionable.

FWIW We are using Jitsi during the Neutron CI meetings every other week. I installed Jitsi app from flathub recently (https://flathub.org/apps/details/org.jitsi.jitsi-meet[1]) and for me it works pretty good now. But I know that some people have problems with sound and they need to reconnect couple of times. It's not always problem that sound is not working at all. Sometimes people can hear part of the other people on call but not all of them. I don't have any more data about it but if we will experience such issues next time during CI meeting, We will try to reach out to You with hopefully more details. honestly i use chromium for video calls and firefox for everything else and i never have issue with any of the differnt video apps using that combination. granted im also still using xorg and pulseaudio not wayland and pipewire but for those that have issues with jitsi if you cant or dont want to use use the flathub app try chromium or chrome if you want the googale build and are having issue with firefox and audio.

...

The mobile clients do seem to work quite well if you need a fallback too.

...

-gmann

...

...

The full setup is well documented [1], and we have free software ansible scripts [2]. This allows thousands of attendees, plus recording and reviewing of the videos.

I very much would love if there was some efforts put in this direction (or some similar setup, as long as it's fully free).

Hoping this helps, Cheers,

Thomas Goirand (zigo)

[1] https://video.debconf.org [2] https://salsa.debian.org/debconf-video-team

On 5/23/22 17:45, Ghanshyam Mann wrote:

...

Yeah, these are more interactive meetings than presentation style. If anyone attending the the meeting I expect they will participate in the discussion sometimes or at least can/should be able to make comments when things are related to their projects/area or so.

-gmann

In a meeting with 30 participants or more, it is impossible that everyone talks. More over, at least one of them will have his/her mic on with some disturbing noise (and this is platform agnostic...).

On Tue, 2022-05-24 at 11:22 +0200, Thomas Goirand wrote: that has not been my experince. for ptgs and other video confernce we can have 30+ and still discuss things. general most people will have there mic muted for alot of the call and only interject if they feel they can add to the converstion or its a topic of interest.

In such a setup, asking questions on the chat (for example, on IRC) is a way more efficient, and usually enough. If not enough, you can always ask the person to join the meeting, if more interactive (unexpected) discussion is needed. Though it'd be surprising if this happens often.

there is really not advantage to having a video call if the majority of the interaction is done over irc or chat. we use video calls to enable higher bandwith comunication then irc and generally try to aovid using video calls as a comunity with a prefernce for irc meeting due to the better logging that enables. so the primary reason for video mettings is to enable multiple people discuss topics rapitly with the visiual queue of if someone want to interject ectra that a void only call would not facilate. so i would think that unless you expect a lot of interaction you should not be using a video call and shoudl be using our default of irc. the other option we could look into perhaps is using matix. it has video capablities and text but i have not personally used that facilaty yet. you can also join via the web with 0 install using say element.io and there are native applicaiton on many operating systmes inclouding ios/andriod. if we were to look at using something other then jitsi then haveing an openstack home server or using rooms on the matrix.org home server may be something we should look into.

Cheers,

Thomas Goirand (zigo)

---- On Fri, 20 May 2022 12:42:28 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----

---- On Fri, 13 May 2022 20:43:57 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----

...

Hello Everyone,

Writing on the top for quick reading as we have a consensus on this.

In today's TC meeting [3], we discussed this topic with Foundation staff and we all agreed to give the release name process handling to Foundation. TC will not be involved in the process. The release name will be mainly used for marketing purposes and we will use the release number as the primary identifier in our release scheduling, automated processes, directory structure etc.

I have proposed the patch to document it in the TC release naming process.

- https://review.opendev.org/c/openstack/governance/+/841800

As the next step, we will have a voice call to figure out how to use the number/name in our development cycle/tooling. Meeting details are below:

* When Tue May 24, 2022 9am – 10am Pacific Time (16:00 - 17:00 UTC) * Joining info Join with Google Meet = meet.google.com/gwi-cphb-rya * Join by phone: (US) +1 563-447-5079 (PIN: 263292866)

To update here: As discussed in the meeting, TC passed the resolution[1] and documented what place to use the release number and name, please reach out to TC if you have any queries on this: - https://governance.openstack.org/tc/reference/release-naming.html [1] https://governance.openstack.org/tc/resolutions/20220524-release-identificat... -gmann

-gmann

...

[1] https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-12-15.00.log.html#l...

-gmann

---- On Fri, 29 Apr 2022 14:47:31 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----

...

---- On Fri, 29 Apr 2022 14:11:12 -0500 Goutham Pacha Ravi <gouthampravi@gmail.com> wrote ----

...

On Fri, Apr 29, 2022 at 8:36 PM 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.

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

Beloved TC,

I'm highly disappointed in this 'decision', and would like for you to reconsider. I see the reasons you cite, but I feel like we're throwing the baby out with the bathwater here. Disagreements need not be feared, why not allow them to be aired publicly? That's a tenet of this open community. Allow names to be downvoted with reason during the proposal phase, and they'll organically fall-off from favor.

Release names have always been a bonding factor. I've been happy to drum up contributor morale with our release names and the stories/anecdotes behind them. Release naming will not hurt/help the tick-tock release IMHO. We can append the release number to the name, and call it a day if you want.

I agree with the disagrement ratio and that should not stop us doing the things. But here we need to understand what type of disagrement we have and on what. Most of the disagrement were cutural or historical where people has shown it emotinally. And I personally as well as a TC or communitiy member does not feel goot to ignore them or give them any reasoning not to listen them (because I do not have any reasoning on these cultural/historical disagrement).

Zed cycle was one good example of such thing when it was brought up in TC channel about war thing[1] and asked about change the Zed name. I will be happy to know what is best solution for this.

1. Change Zed name: it involve lot of technical work and communciation too. If yes then let's do this now.

2. Do not listen to these emotional request to change name: We did this at the end and I do not feel ok to do that. At least I do not want to ignore such request in future.

Those are main reason we in TC decided to remvoe the name as they are culturally, emotionally tied. That is main reason of droping those not any techncial or work wise issue.

[1] https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2022-03...

-gmann

...

I do believe our current release naming process is a step out of the TC's perceived charter. There are many technical challenges that the TC is tackling, and coordinating a vote/slugfest about names isn't as important as those. As Allison suggests, we could seek help from the foundation to run the community voting and vetting for the release naming process - and expect the same level of transparency as the 4 opens that the OpenStack community espouses.

Yes we will offcourse open to that but at the same time we will be waiting for the foudnation proposal to sovle such issue irespective of who is doing name selection. So let's wait for that.

-gmann

...

...

[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

On 2022-04-29 21:39:18 +0200 (+0200), Cedric Lemarchand wrote:

Maybe a best of breed approach would be to have both, like Ubuntu releases. It does not solve the time consuming and others issues regarding naming choices but I see it as a good consensual solution at this time.

That's essentially the status quo. The currently approved (and recently revised) process says we have both a release name and year-based version number: https://governance.openstack.org/tc/reference/release-naming.html The proposal under discussion now is to drop the name, so only the number remains: https://review.opendev.org/839897 -- Jeremy Stanley