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