Open Stack

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

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

-gmann


 ---- On Fri, 29 Apr 2022 14:47:31 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > 
 >  ---- On Fri, 29 Apr 2022 14:11:12 -0500 Goutham Pacha Ravi <gouthampravi at gmail.com> wrote ----
 >  > 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 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-08.log.html#t2022-03-08T14:35:26
 > 
 > -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
 >  > 
 >  > 
 > 
 >