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