Open Stack

Thanks for kick starting the conversation, Jim :D

On Wed, 2019-08-21 at 10:34 -0700, James E. Blair wrote:
> Thanks for the excellent feedback!
> 
> Graham Hayes <gr at ham.ie> writes:
> 
> > On 21/08/2019 17:15, James E. Blair wrote:
> > > https://review.opendev.org/675788 - Stop naming releases
> > 
> > As I said in the review I am -1 on this, due to the amount of
> > tooling
> > that assumes names, and alphabetical names. also, we need something
> > to
> > combine Nova v20 and Designate v9 into a combined release (in this
> > case
> > Train), and moving to a new number would make this interesting
> 
> What about using dates?  We used to use dates as version numbers,
> which
> we found was problematic.  But what if we used dates for the
> coordinated
> release but not as software version numbers?

I think this is just me being a wordy person, but I'd like to avoid
numbers. It becomes very generic, not identifiable, and it gets lost
amongst everything. There's something pleasant about being able to talk
about a release with a name (Juno, Kilo, etc) that  actually means
something. 

> 
> > > https://review.opendev.org/677745 - Name releases after major
> > > cities
> > 
> > +1 from me on this, I like the idea, and is less controversial
> 
> Yeah, I really like this one too.

+2. I've included my thoughts in the patch.

> 
> > > https://review.opendev.org/677746 - Name releases after the ICAO
> > > alphabet
> > 
> > A solid "backstop"[1] option, but not something we should actively
> > promote in my opinion.
> 
> We know what the TC doesn't want, now we need to find out what it
> does
> want.  ;)
> 
> > This also only works for V->Z as I don't to ever have a OpenStack
> > Alpha
> > / Beta release when Nova will be on v27 and over a decade old.
> 
> Yes, I probably should clarify that many of these options get us to
> Z,
> and that we should separately start thinking about what happens after
> Z.  Alexandra plans to start that discussion soon.

Hoping to kick start that conversation off the back of this one. Let me
know if anyone disagrees, but I think tackling one issue at a time is
best. At the very least, we clarify what's going on here - and then we
can adapt and change.

> 
> > > https://review.opendev.org/677747 - Ask the Foundation to name
> > > releases
> > 
> > I am not sure how I feel about this - I think this is a community
> > deliverable, and as such *we* should name it.

Ditto. I included my thoughts on the review. But I think this is out of
the Foundation's scope and I personally would not like to add it to
their scope. This is a community driven project, and I believe the
community should name it :D (regardless of our issues...)

> > 
> > > https://review.opendev.org/677748 - Name releases after random
> > > words
> > 
> > -1 - I feel that we will get into the same issues we have for the
> > current process of bikeshedding over words[2], without adding any
> > benefits.
> 
> To be clear about this one -- the proposal is for the TC to decide
> among
> a slate of 10 candidates produced by random number generator.  In
> practice, this probably will mean picking from among 2 or 3
> boring-but-okay names and ignoring 7 bad-or-stupid names.  I don't
> expect the discussions to be contentious.  Maybe produce the
> occasional
> chuckle.
> 

Maybe. I can see this working, tbh. But it feels a little less tied to
the project and more at random. The city option (as you've expressed
desire for too) just feels like it creates more meaning.

> I agree though, cities are better.
> 
> > > https://review.opendev.org/677749 - Clarify the existing release
> > > naming process
> > 
> > Seems OK to update the docs with this if we stick with the status
> > quo.
> > Not sure it would have avoided the current issues if it was in
> > place,
> > but lets see.
> 
> I'm personally not in favor of it and also don't think it would have.
> 
> > > The last one is worth particular mention -- it keeps the current
> > > process
> > > with some minor clarifications.
> > 
> > 
> > Zane put up 2 more:
> > 
> > https://review.opendev.org/#/c/677772/ -
> > Clarify proscription of generic release names
> > https://review.opendev.org/#/c/677771/ - Align release naming
> > process
> > with practice
> > 
> > These document the current state of play, and is a +1 from me if
> > we stick with the current process.
> 
> I agree they bring them closer to describing practice (but still not
> 100% in my view).  But I just want to take a step back and remind
> folks
> that we are having this conversations because the current process is
> unpleasant.  It is resulting in contention and disagreement about
> things
> which have no bearing on our producing good software.  I think we
> should
> take this opportunity to choose a new process which produces boring
> non-controversial names and ideally start planning to phase them out
> altogether soon.

My vote is to finish Z before we make any changes. Finish what you
started, even if it's hard. And from there we can say we've learnt from
this... experience... and work on something that's better. Jumping off
the alphabet bandwagon at U will look odd to the user base.

> 
> > Overall, these are all short(ish) term solutions - we need to do
> > something more drastic in ~ 3 years for the Z->A roll over (if we
> > keep
> > doing named releases).
> 
> Agreed.
> 
> -Jim
> 
-- 
Alexandra Settle <a.settle at outlook.com>
IRC: asettle