Open Stack

On Fri, Apr 29, 2022 at 8:36 PM Slawek Kaplonski <skaplons at redhat.com> wrote:
>
> Hi,
>
>
> During the last PTG in April 2022 in the TC meeting we were discussing our release naming policy [1].
>
> It seems that choosing appropriate name for every releases is very hard and time consuming. There is many factors which needs to be taken into consideration there like legal but also meaning of the chosen name in many different languages.
>
>
> 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