Open Stack

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?
year.release i think would work
e.g. 20.01 20.02
i donthink think we shoudl use yy.mm as that qould cause confution with things like ubuntu

i think that was more or less what we did before mybe it was 2020.1 but i prefer names but
am not opposed to this.
> 
> > > 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.
i like this too although i would proably expand it to city,region or geograpical feature

e.g.  artic, bayou, canyon, delta/desert, are gograpical feature / regions that i think
would be in a similar spirit to cities.
> 
> > > 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.  ;)
> 
:) it may  be a bit too soon. lets decide the day before we ship...
> > 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.
some could apply beyond that but ya  when we get to Z 
it might be a good time to revisit it again.
> 
> > > 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.
if we did this i would prefer there to still be a comunity vote element and
have the TC prepare a list of viable names and comunity decide form that list
rather then it be totally a tc decision 
> > 
> > > 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.
> 
> I agree though, cities are better.
yep although another variation on this would be for the TC to select a theme
and have the community suggest words related to that theme and then ballot on that.
e.g. use a human random number generort seed with a general directly like trying to heard
cat, the resonce will be random and most will ignore the request but it would be an option.
> 
> > > 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.
personaly i was watching but mostly outside of the process but i did not feel it was
as big of an issue as it has been suggested how this release was handeled. i think
most people acted in good intent. that said i also get that we want to improve going forward
and it good we can have this discourse as a community on how to do that.
> 
> > > 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.
> 
> > 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
>