[tc] Release naming process
On 21/08/2019 17:15, James E. Blair wrote:
> In the previous thread about the U release name, we discussed how the
> actual process for selecting the name has diverged from the written
> process. I think it's important that we follow our own processes, so we
> should reconcile those. We should change our actions or change the
> Based on the previous discussion, I've proposed 6 changes to
> openstack/governance for some initial feedback. We can, of course,
> tweak these options, eliminate them, or add new ones.
> Ultimately, we're aiming for the TC to formally vote on one or a small
> number of changes similar to these.
> I'd like for anyone interested in this to review these options and leave
> feedback on the changes themselves, or here on the mailing list. Either
> is fine, and all will be considered. Leaving "code-review" votes on the
> changes themselves will help us gauge relative support for the different
> In a week, I'll collect the feedback and propose a next step.
> 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
> https://review.opendev.org/677745 - Name releases after major cities
+1 from me on this, I like the idea, and is less controversial
> https://review.opendev.org/677746 - Name releases after the ICAO alphabet
A solid "backstop" option, but not something we should actively
promote in my opinion.
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.
> 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, without adding any
> 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.
> The last one is worth particular mention -- it keeps the current process
> with some minor clarifications.
Zane put up 2 more:
Clarify proscription of generic release names
https://review.opendev.org/#/c/677771/ - Align release naming process
These document the current state of play, and is a +1 from me if
we stick with the current process.
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).
1 - If you are in the europe area, or follow our news, I am sorry
2 - I am aware a lot of the TC discussions are bikeshedding over words,
but lets try and limit it?