Open Stack

On Mon, 2022-05-02 at 19:52 +0200, Thomas Goirand wrote:
> On 5/2/22 18:14, Ghanshyam Mann wrote:
> >   ---- On Mon, 02 May 2022 10:49:09 -0500 Thomas Goirand <zigo at 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.
> 
> Ok, sorry... :/

i actuly dont find that to be offensive but im aware coluteral norms differ on this.
if this was an in person conversation i would not consider it inappropriate, agressive or rude
so i dont think its unsuitable for the list or bad nettiqute.
> 
> > 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...
well ofr most people i dont think it will matter. the only real differnce between the two release is
the upgrade testing and considerations . both will be as as stable and feature rich as each other, actully given
my personal expericne the second release of the year tends to have slight less feature as more people tend to take time off
in the nothern hemispehe summer then the do in the winter and as a result we deliver less feature in the second release.

i strongly agree with what dan and you previrously said regarding not implying primacy of one release over the other.
i would hope that deploying every release continues to be the norm and dont think we shoudl be doing anything with regard to nameing
that would discurage that. i have fully expected that we woudl tag teh tick/tock release on the release page as zigo menthioned.
although ill admit i find the half data half release number to be a bit confusing too

if we are going date based i would have prefered 2022.03 2022.09 or  basically year.month in YYYY.MM or YY.MM format
that avoid any percetions ectra related to .0, .1 vs .2

in generally im also ok with keeping nameing and delegeting the selection to the foundation.
i agree that the overheard of the curent tc process seams to outweigh the benifit and i think the comuinty vote was preferable to the
current tc process but delegating release nameing to the foundation make is simple a marketing choice and remove much of the overhead.

im not really stongly opipioned on named vs numbered releases.
for ubuntu release i almost alwyas adress them by the numbers not the names as the names are kind of confusing to me since they wrapped around.
for openstack i always went by the names. out downstream product is numbered so form a downstream perspective there is always
an indirection anyway so name vs number will have littel impact from that point of view.

although is we do use names i think aardvark is the prime candiate for AA :)
> 
> Cheers,
> 
> Thomas Goirand (zigo)
>