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@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@outlook.com> IRC: asettle