On Wed, 2019-08-21 at 10:34 -0700, James E. Blair wrote:
Thanks for the excellent feedback!
Graham Hayes gr@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