[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[tc] Release naming process

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?

>> 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.

>> 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.

>> 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.
>> 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

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.

> 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).