[tc] Release naming process
Hi, 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 process. 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 options. In a week, I'll collect the feedback and propose a next step. https://review.opendev.org/675788 - Stop naming releases https://review.opendev.org/677745 - Name releases after major cities https://review.opendev.org/677746 - Name releases after the ICAO alphabet https://review.opendev.org/677747 - Ask the Foundation to name releases https://review.opendev.org/677748 - Name releases after random words https://review.opendev.org/677749 - Clarify the existing release naming process The last one is worth particular mention -- it keeps the current process with some minor clarifications. -Jim
On 21/08/2019 17:15, James E. Blair wrote:
Hi,
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 process.
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 options.
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"[1] 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[2], without adding any benefits.
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: 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. 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). - Graham 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?
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?
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 chuckle. 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).
Agreed. -Jim
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. ;)
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.
:) it may be a bit too soon. lets decide the day before we ship... 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
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
On 8/21/19 6:15 PM, James E. Blair wrote:
Hi,
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 process.
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 options.
In a week, I'll collect the feedback and propose a next step.
https://review.opendev.org/675788 - Stop naming releases https://review.opendev.org/677745 - Name releases after major cities https://review.opendev.org/677746 - Name releases after the ICAO alphabet https://review.opendev.org/677747 - Ask the Foundation to name releases https://review.opendev.org/677748 - Name releases after random words https://review.opendev.org/677749 - Clarify the existing release naming process
The last one is worth particular mention -- it keeps the current process with some minor clarifications.
-Jim
Hi, I'm quite happy to see that, so far, the "don't change anything in the naming process" option seems popular. Thomas
On Wed, Aug 21, 2019 at 09:15:46AM -0700, James E. Blair wrote:
Hi,
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 process.
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 options.
In a week, I'll collect the feedback and propose a next step.
https://review.opendev.org/675788 - Stop naming releases
This!, well A variation. I suggest 'Twenty' not '20' The process used to be fun. It isn't any more. This specific instance has created several rifts in our community, hurt feelings and more than a little stress. Apart from that as we have fewer developers it takes resources that are now better spent elsewhere. Yes it will make some of out tooling that assumes alphabetical order a little strange but not too bad, and we were going to have to fix that soon anyway. Yours Tony.
participants (6)
-
Alexandra Settle
-
corvus＠inaugust.com
-
Graham Hayes
-
Sean Mooney
-
Thomas Goirand
-
Tony Breeds