)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"786145e2ac44d98611c155a5d0c1f4d561e6bc56","unresolved":true,"context_lines":[{"line_number":10,"context_line":"individual project, even in the projects\u0027 own release notes or"},{"line_number":11,"context_line":"documentation. This may cause confusion to operators and contributors"},{"line_number":12,"context_line":"for projects under OpenStack governance, but can be used standalone or"},{"line_number":13,"context_line":"as part of other systems -- such as Ironic."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Instead, ensure that in project-specific documentation that the project"},{"line_number":16,"context_line":"name is the first thing listed, preventing confusion in standalone"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"9412836e_e7de0519","line":13,"updated":"2023-02-20 19:33:02.000000000","message":"I don\u0027t understand this. The projects still have a version number, and if someone is going to use that project standalone, that\u0027s the only version number they should need to care about. It seems to me like the change you\u0027re making in the next file means those people have to care about two versions (which are different, but also the same?)\n\nIMHO, the coordinate release is the thing stamped with 2023.1 and that _is_ the openstack coordinated release. Projects not participating in that release surely wouldn\u0027t want to suddenly have two version numbers, especially given that one won\u0027t line up with the rest of the things called 2023.1 right?","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"c0ce4c248b94e55cff19d5ace6c1823d6f3565f2","unresolved":true,"context_lines":[{"line_number":10,"context_line":"individual project, even in the projects\u0027 own release notes or"},{"line_number":11,"context_line":"documentation. This may cause confusion to operators and contributors"},{"line_number":12,"context_line":"for projects under OpenStack governance, but can be used standalone or"},{"line_number":13,"context_line":"as part of other systems -- such as Ironic."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Instead, ensure that in project-specific documentation that the project"},{"line_number":16,"context_line":"name is the first thing listed, preventing confusion in standalone"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"b05a02f8_684f85af","line":13,"in_reply_to":"0f365a1d_7614f1ff","updated":"2023-02-20 19:48:24.000000000","message":"I am wondering on how \u0027OpenStack Zed/2023.1\u0027 is confusing than \u0027zed/2023.1\u0027 ? How current users know what the \u0027zed\u0027 is? I think adding \u0027openstack\u0027 make it more clear that what is \u0027zed/2023.1\u0027 here is.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"0aa43bc4ebfa9146a344aceb99be7a9cae8f5ed2","unresolved":true,"context_lines":[{"line_number":10,"context_line":"individual project, even in the projects\u0027 own release notes or"},{"line_number":11,"context_line":"documentation. This may cause confusion to operators and contributors"},{"line_number":12,"context_line":"for projects under OpenStack governance, but can be used standalone or"},{"line_number":13,"context_line":"as part of other systems -- such as Ironic."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Instead, ensure that in project-specific documentation that the project"},{"line_number":16,"context_line":"name is the first thing listed, preventing confusion in standalone"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"0f365a1d_7614f1ff","line":13,"in_reply_to":"9412836e_e7de0519","updated":"2023-02-20 19:44:02.000000000","message":"Right now, if a user opens up the Ironic release notes, for example, they get a header of the following (from \nhttps://docs.openstack.org/releasenotes/ironic/zed.html ) \"Zed Series (20.2.0 - 21.1.x)\".\n\nThe word OpenStack is nowhere in the main section of the release notes.\n\nUnder the change that was landed without my vote; that headline would now say \"OpenStack 2023.1 (Ironic x.y.z - x.y.z)\". It\u0027s my assertion that having that header specifically indicate OpenStack before Ironic is going to promote confusion to users who use Ironic standalone, with minimal knowledge of OpenStack -- a pattern we explicitly encourage in https://ironicbaremetal.org. We must consider this case when making this decision -- just because a project is a part of an integrated release, doesn\u0027t mean it\u0027s *only* useful as part of an integrated release.\n\nIronic has been dealing with this concept of \"two versions\" the entire time; just now with the OpenStack version changing to a number, it adds even more confusion when in writing. When talking about the content of my change (which you\u0027ve not commented on), that content still contains 2023.1 -- which OpenStack users will recognize -- while still listing the project name first, which is what standalone users will recognize.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"2d18c48777be4c8b747a1421dd51edf7008d858a","unresolved":true,"context_lines":[{"line_number":10,"context_line":"individual project, even in the projects\u0027 own release notes or"},{"line_number":11,"context_line":"documentation. This may cause confusion to operators and contributors"},{"line_number":12,"context_line":"for projects under OpenStack governance, but can be used standalone or"},{"line_number":13,"context_line":"as part of other systems -- such as Ironic."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Instead, ensure that in project-specific documentation that the project"},{"line_number":16,"context_line":"name is the first thing listed, preventing confusion in standalone"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"223afb6f_e2e23a0e","line":13,"in_reply_to":"b05a02f8_684f85af","updated":"2023-02-22 01:09:59.000000000","message":"Jay, I wouldn\u0027t call it two versions, but more like two identities. We\u0027ve worked to balance the visceral reaction \"eww openstack!\" crowd with the happy \"yay openstack!\" crowd. The commonality really being in how we walk the line. At least, that is *my* personal perception.\n\nOverall, I do worry there is conflation of \"named coordinated release\" and individual project version numbers, since we can\u0027t realistically map and expect one to serve as the other. Nor can we do it in the opposite direction without creating undesirable impacts.\n\nThere is a happy ground someplace, we need to talk through it in higher bandwidth.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"786145e2ac44d98611c155a5d0c1f4d561e6bc56","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0c109cad_5be0937b","updated":"2023-02-20 19:33:02.000000000","message":"I may be missing something here, but I don\u0027t see how this makes things anything other than *more* confusing, but maybe I\u0027m missing something?","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"03da65002e7066224dfe5981ef4b43704d4bd4b7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3254a671_8e3d9bb4","updated":"2023-02-20 19:30:48.000000000","message":"new versioning template seems confusing to me. Added inline suggestion to cover both case.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"6e6c4ca82dc737a91d79af6ceb067c4dd44be204","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"81be1948_7bbeb3db","updated":"2023-02-20 20:08:53.000000000","message":"After conversation in IRC, I decided the more prudent path was to explicitly document that standalone projects are free to omit the OpenStack integrated version moniker entirely when it\u0027s not contextually useful or relevant.","commit_id":"9ba5faefea68504866f5d45f7fae39f9c2901caf"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"5c5de9faceaa076945e668a5ef2af48246f4b228","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a9bd9fdb_30132b39","updated":"2023-02-21 03:36:11.000000000","message":"I haven\u0027t been around here for a while, but this feels really icky to me.\n\nI massively disagree with this change, if you think that someone will walk away from something just because it says \"OpenStack\", then let\u0027s fix that.  The solution isn\u0027t to wipe it off so they don\u0027t see it, because they will see it, in the docs theme, and in the URLs, and in the place it\u0027s hosted, and so many other places.\n\nYou have a branding problem of the project seeming like it can\u0027t just be ran on its own.  Maybe a big FAQ or a big o\u0027l red message (exaggerating) on the docs that says \"you don\u0027t need a full openstack deployment to use ironic, you can use it standalone just like MaaS!   read more...\"\n\nhuge and massively disappointing change if it merges.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"f1c9a81c28b92dd23c969da001e69cbcb2a71585","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b32bb4d7_d165fb75","updated":"2023-02-21 20:17:28.000000000","message":"I think it\u0027s fine to enable both use cases. OpenStack is a collection of components under a common technical governance, with an integrated release every 6 months. Each component is versioned separately, so it\u0027s totally OK to say \"Nova 48.0.1\" without mentioning that it\u0027s part of OpenStack 2027.2 \"Xephyr\" in my book.\n\nThat enables standalone usage but also mixed version usage like in CERN where they run a lot of OpenStack components but with versions coming from different OpenStack integrated releases.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"df03c881c5af34b43b36ffd66469024245c85166","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"cd905f9d_c4fa1e27","updated":"2023-02-23 16:15:09.000000000","message":"JayF asked for us to vote on this, so I\u0027m doing that.\n\nI think this is a net loss in terms of consistency. As Sylvain said (and Dmitriy echoed), I think the consistency gain of having the coordinated release version mentioned very much outweighs the potential confusion of someone with a standalone mindset for one of the services. I could go into the reasons why I think that confusion is unlikely to be caused by such a mention, but I think we\u0027ve mostly been over it.\n\nJayF also asked us to judge this in isolation without the larger context of why it may or may not be important. Without any supporting context I really don\u0027t see any benefit to the change. But because think the context is important, I also did a little chatting with some other projects that are deployable standalone. I honestly don\u0027t see any other projects (at least the ones I talked to and/or represent) likely to want to omit the OpenStack verbiage nor the coordinated release version number from their docs. That would make any single deviation from the current guidelines even more of a divergence and less helpful overall.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"b026a957a8ae387ccb53208867d620a3726251ad","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"50896444_816c5453","updated":"2023-02-21 23:19:30.000000000","message":"Not sure if I have to RC+1 my own patch; but I am. \n\nThis patch demonstrates a compromise, allowing projects to both use a full version (including integrated release) and a truncated, project-only version.\n\nIf you are OK with the concept but want the wording changed, please put that directly in a comment. I will not be responding further to larger, philosophical concerns or comments.\n\n\nIt is not my intent to engage any further in the side conversations around this -- this isn\u0027t a debate around what \"standalone\" services are. If you want to have that debate; you can, I won\u0027t be participating in it anymore w/r/t this change due to the unkind nature of the words and statements about myself and the Ironic community about the semi-related side conversations that have occurred around this change in IRC.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"83af6f8e7b47e2a34542a514650efd20e5f5af8d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"4081b27e_eecac0ac","updated":"2023-02-22 17:10:57.000000000","message":"Sorry, can\u0027t R-V but I\u0027m quite afraid of the possibility of remove the mention of the best thing we had for a very large set of projects led by a foundation : a coordinated release.\n\nIMHO, an OpenStack release number (or name) is the cement that makes OpenStack a non-siloed gang of projects like the apache foundation and while we fully accept the possibility to have a project be standalone, this project is still fully part of the fully tested ecosystem and shall be proud of being part of it.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"e4f1c39975374a47765cc7c1f9320828fbd1066f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ef1bbbc3_21d266f6","updated":"2023-02-21 15:39:26.000000000","message":"fixing my vote","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"fcfc6a13e227279ac19a97e3b88ba1704a82341e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f4c3a2f7_23340fb2","updated":"2023-03-01 18:09:10.000000000","message":"on rethinking on all the use case I feel original one is better one and cover both the use case of integrated and standalone.\n\n* OpenStack 2023.1 (Nova 27.0.0)\n1. It covers the standalone use case by having the project version\n2. It covers the integrated use case by having OpenStack coordinated version\n\n* Nova 27.0.0\n1. It covers the standalone use case by having the project version\n2. It DOES NOT cover the integrated use case which means users using projects in integrated way will not get the information from doc/release notes\n\nI think first (existing) version template is good as it cover both use case.\n","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"9538f72120a6c9b35024decc7dc39fdbc49ca96d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"e454757a_f782fe15","updated":"2023-02-20 20:11:30.000000000","message":"patchset 3 is just whitespace cleanup","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"2d18c48777be4c8b747a1421dd51edf7008d858a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"1e6b59ca_de0f5151","in_reply_to":"2cc5f237_418042ce","updated":"2023-02-22 01:09:59.000000000","message":"Mohammed, I completely agree with your second paragraph! As for the third, I think it is not just a project level branding issue, ultimately it is a weight of OpenStack\u0027s perception issue. It is not just an issue at the project level. That can independently be managed and I think thus far has fairly well. But if a project has to start referring to long form extra verbose statements in common docs as part of mandatory rules, that is going to create friction because a project is going to know how that will be perceived through their own experience.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"891e0530c9661201144eeb0c77b93fdbe701eb1e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2cc5f237_418042ce","in_reply_to":"a9bd9fdb_30132b39","updated":"2023-02-21 04:08:05.000000000","message":"right. I am also not sure why Ironic with OpenStack brand is confusing and discouraging for users and to get more clarity do we have such a example where users have shown objection and confusion for Ironic using \u0027OpenStack\u0027 or its release versions/name in doc/release notes? or it\u0027s is just community impression? \n\nBecause if we know such example then it will be easy to make the user/document clear about Ironic that it is both 1. OpenStack integrated deployment software as well as 2. standalone like many other OpenStack projects like Tacker, Swift ?","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"2d18c48777be4c8b747a1421dd51edf7008d858a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"7d452072_5b05a3a4","in_reply_to":"b32bb4d7_d165fb75","updated":"2023-02-22 01:09:59.000000000","message":"I concur, and I would expect that given the model is inclusion of x release into y coordinated release, it makes sense to enable that pattern. The author of a release note or inline documentation should know from which the context they are authoring from, and appropriately convey that context to the readers. How they do so is situational, and I really think there is no \"one singular\" way to do so with a large project such as ours without unintended side effects. I feel like this calls back to the old doc guidelines days 5-6 years ago when we had people going through and changing docs outside of context because it appeared in their grep of the code, not understanding the original author\u0027s intent.\n\nMore concerning from the discussion is an inherent change to what is the coordinated release and how it is perceived as a version itself, which cascades, but one conundrum at a time, I guess.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"b026a957a8ae387ccb53208867d620a3726251ad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"e6d86e9b_08efb511","in_reply_to":"b32bb4d7_d165fb75","updated":"2023-02-21 23:19:30.000000000","message":"This is what my intention is. The only reason it appears as a change in the repo is because the previous governance change was landed without my review while I was out with COVID.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"}],"reference/release-naming.rst":[{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"8d02f34890993ae5d99ae146a08e1f04243b4174","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  branches are going to use."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* Release notes: For the version of specific project use combined OpenStack release and"},{"line_number":43,"context_line":"  the project\u0027s version, like \"OpenStack 2023.1 (Nova 27.X.Y)\"."},{"line_number":44,"context_line":"  There should not be OpenStack release name, like \"Antelope\" included in the version."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e7a164f6_5461b5de","side":"PARENT","line":43,"updated":"2023-02-20 20:30:19.000000000","message":"The conundrum here is we have distributed release notes as part of individual projects which comprise an OpenStack. Having multiple documents stating \"OpenStack 2023.1 (Component x.y.z)\" seems like it is going to create confusion, as then one project may be interpreted for speaking for the whole of the community just based upon release notes content from one individual project, which is obviously problematic.\n\nWhich makes me wonder, what is the *real* problem we\u0027re trying to solve.\n\nFor what it is worth, if the original triggering desire is to re-frame \"What is OpenStack\", then I would advise scheduling time with the board to discuss given the heartburn the subject has traditionally generated. Of course, if the underlying motive is to also stamp out individual project identity, then I believe the complex naming scheme is not going to help unity within the community.","commit_id":"723167429daf5bb3bc886dcecf94f97288204088"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"36c57fe875664d46c405abad5e1a17f303b13131","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  branches are going to use."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* Release notes: For the version of specific project use combined OpenStack release and"},{"line_number":43,"context_line":"  the project\u0027s version, like \"OpenStack 2023.1 (Nova 27.X.Y)\"."},{"line_number":44,"context_line":"  There should not be OpenStack release name, like \"Antelope\" included in the version."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8685f4ed_39f6296e","side":"PARENT","line":43,"in_reply_to":"3741ad84_40b5a2b1","updated":"2023-02-20 21:08:41.000000000","message":"I have no idea how this got confused with \"reframing \u0027What is OpenStack\"\u0027. This is all about referring to openstack coordinated releases in a consistent way so that our docs match and our users aren\u0027t confused.\n\nTo be honest, I was originally in favor of doing away with the per-project versions entirely in some way and going for the 2023.1 sort of numbering for the projects *and* the releases. I was an outlier in that, but this discussion has me re-thinking that maybe it\u0027d be better for consistency as at the moment, I\u0027m really concerned we\u0027re going to compromise our way to something than is an order of magnitude more confusing, if we have to refer to versions as \"Project 29.1.2, part of the totally-cool-and-open-to-outside-projects-too-click-here-to-join-our-mailing-list coordinated release of OpenWaitForItStack 2023.1, code named antelope because anelopes are cool\".","commit_id":"723167429daf5bb3bc886dcecf94f97288204088"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"2d18c48777be4c8b747a1421dd51edf7008d858a","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  branches are going to use."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* Release notes: For the version of specific project use combined OpenStack release and"},{"line_number":43,"context_line":"  the project\u0027s version, like \"OpenStack 2023.1 (Nova 27.X.Y)\"."},{"line_number":44,"context_line":"  There should not be OpenStack release name, like \"Antelope\" included in the version."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e22f3543_0e95736e","side":"PARENT","line":43,"in_reply_to":"8685f4ed_39f6296e","updated":"2023-02-22 01:09:59.000000000","message":"I\u0027d like to schedule a dedicated call to discuss this. I\u0027ve spent a lot of energy writing replies, only to delete them because of concern over how my words will be interpreted while also trying to balance just how much context include, and then worry about it being misconstrued. Ultimately, I have concerns based upon how a mandate is perceived. Others I spoke to this morning even expressed the same concerns I have before I even got a chance to express my own feelings on the matter.\n\nI think this all comes from good places, except maybe eliminating project versioning (and thus inherently hurting identity)... or maybe not, but I think higher bandwidth discussion is needed so we can discuss and understand the competing concerns and challenges we\u0027re all attempting to solve for.\n\nIs there a preferred day/time for 30 minutes?","commit_id":"723167429daf5bb3bc886dcecf94f97288204088"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"f80ea2334524b0980c70e86db28394e1569a0603","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  branches are going to use."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"* Release notes: For the version of specific project use combined OpenStack release and"},{"line_number":43,"context_line":"  the project\u0027s version, like \"OpenStack 2023.1 (Nova 27.X.Y)\"."},{"line_number":44,"context_line":"  There should not be OpenStack release name, like \"Antelope\" included in the version."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3741ad84_40b5a2b1","side":"PARENT","line":43,"in_reply_to":"e7a164f6_5461b5de","updated":"2023-02-20 20:45:15.000000000","message":"I am not sure from where *re-framing \"What is OpenStack\"* coming here. And why we should not discussed it in TC and discuss in board?\n\nJust to give more context about background. When TC shifted the primary identifier of OpenStack release from name to version, there were confusion in many projects on how to use the openstack release version along with project version as both are number here. Previously documented were used to have \"OpenStack \u003crelease name\u003e project version\" so this is not just about adding \u0027OpenStack version\u0027 here it is more like providing guidelines of using release version in better way in place of previously used release name.","commit_id":"723167429daf5bb3bc886dcecf94f97288204088"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"03da65002e7066224dfe5981ef4b43704d4bd4b7","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0be5e36f_fcf39adb","line":48,"range":{"start_line":48,"start_character":3,"end_line":48,"end_character":15},"updated":"2023-02-20 19:30:48.000000000","message":"it seems like Nova 2023.1 version and it is hard to know 2023.1 is openstack version.\n\nI think we are missing the point of adding \u0027openstack\u0027 at the start. if we are adding openstack release version then we MUST add \u0027openstack\u0027 otherwise release version say \u00272023.1\u0027 can be very confusing.\n\nIMO we can recommend two set of guidelines here:\n\n1. If project wants to use the openstack release version then use this template: \"OpenStack \u003crelease version\u003e (\u003cproject\u003e \u003cproject vesion\u003e)\" Example: \"OpenStack 2023.1 (Nova 27.0.0)\"\n\n2. If project does not want to use the *openstack* word at the start then they need to avoid using openstack release version also. Basically this template:  \"\u003cproject\u003e \u003cproject vesion\u003e\" For example, \"Nova 27.0.0\"","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"2237bb819ac454fe670f7fa3129d4e889511e41b","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c23398f2_3b33365f","line":48,"range":{"start_line":48,"start_character":3,"end_line":48,"end_character":15},"in_reply_to":"0be5e36f_fcf39adb","updated":"2023-02-20 19:32:53.000000000","message":"But this is to cover both the cases if we do not get any agreement on single one. My preference is to choose single template only for consistency.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"8d02f34890993ae5d99ae146a08e1f04243b4174","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7b419d27_448c2d2e","line":48,"range":{"start_line":48,"start_character":3,"end_line":48,"end_character":15},"in_reply_to":"26f05b69_a8f945f2","updated":"2023-02-20 20:30:19.000000000","message":"Dan, I think you\u0027ve got a valid point in terms of cross referencing for versions on specific OpenStack stable streams, yet I do wonder if there is a better way to express cross-version compatability and dependencies outside of humans writing words in release notes.\n\nJay, I think your hitting a root issue even if it is not the intent of the original change, branding itself is more of a topic which should be discussed at a higher level, given it has trademark, and marketing implications.\n\nHonestly, it seems like there is a middle ground here \"Project x.y.z - Part of OpenStack year.rev\" to allow direct correlation and statement of origin.  Which also helps avoid the confusion some of the different and needful release models can create.\n\nFrom a bigger picture standpoint, we do need to be mindful that individual projects have lives of their own. They release as part of OpenStack. We should champion and encourage their growth as it only makes OpenStack stronger by the project becoming a source of usage and driver of integration.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d13c8e37ef518de16c6212a8a3d66bd27b24bd0e","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"}],"source_content_type":"text/x-rst","patch_set":1,"id":"deba11cb_a454abbd","line":48,"range":{"start_line":48,"start_character":3,"end_line":48,"end_character":15},"in_reply_to":"c23398f2_3b33365f","updated":"2023-02-20 19:37:55.000000000","message":"Right, agree. If you\u0027re referring to a specific version of a project, then the project semverish version is what you want, regardless of the coordinated release being discussed. If you\u0027re writing things about upgrades between coordinated releases, and especially if you\u0027re discussing cross-project stuff, you want to refer to that other project in the same openstack release. So if I was saying \"As of 2023.2, Nova requires Cinder 2023.1 because the attachment API version has changed\", that lets me symbolically refer to the fact the the cinder that was part of the last coordinated release, without needing to know what the actual version was, and without the reader having to go look it up.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"2e1841778b15ba06531f0250424e45eba6562ff5","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"}],"source_content_type":"text/x-rst","patch_set":1,"id":"26f05b69_a8f945f2","line":48,"range":{"start_line":48,"start_character":3,"end_line":48,"end_character":15},"in_reply_to":"deba11cb_a454abbd","updated":"2023-02-20 19:47:36.000000000","message":"Putting OpenStack at the start of the version specifier has a massive side effect which is unacceptable in indicating that OpenStack\u0027s brand is more important than that given projects\u0027. I do not like the implication of that, I don\u0027t think it\u0027s healthy for individual projects, and I think it will have negative implications on one of our biggest spots of user and contributor growth: external integrations.\n\nI am fine to talk about other options to make it clear what we\u0027re talking about; I am not OK with every version identifier for a standalone openstack project be required to prefix it with \"OpenStack\".","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"786145e2ac44d98611c155a5d0c1f4d561e6bc56","unresolved":true,"context_lines":[{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"},{"line_number":52,"context_line":"  just version of OpenStack, there should be only version number used, like"}],"source_content_type":"text/x-rst","patch_set":1,"id":"733fda28_8d1ad9fa","line":49,"updated":"2023-02-20 19:33:02.000000000","message":"This doesn\u0027t really make any sense to me. When we eliminated the option of actually changing the project versions to use the date-based format, we said that was because the project is versioned like semver, but the coordinated release is the date-based thing. This change makes it look like there are two versions of nova that refer to a single thing, which I think is much more confusing.\n\nAlso, I\u0027m not really sure what the use of \"Series\" in this example really means.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"1e521be75f35b3e7303c886c8ed01873e7210328","unresolved":true,"context_lines":[{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"},{"line_number":52,"context_line":"  just version of OpenStack, there should be only version number used, like"}],"source_content_type":"text/x-rst","patch_set":1,"id":"97e7131b_cc1ab639","line":49,"in_reply_to":"1d9f36c1_7c8be3af","updated":"2023-02-27 16:08:49.000000000","message":"what about something like:\n\n* Nova 27.0.0 (OpenStack 2023.1) if project is part of the coordinated release\n\nand then something like:\n\n* Ironic 21.0.0 if project is standalone and not part of the coordinated release.\n\nIMO that way it may be less confusing and give projects more flexibility to mark it as part of the coordinated release or not. Wdyt?","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"8d02f34890993ae5d99ae146a08e1f04243b4174","unresolved":true,"context_lines":[{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"},{"line_number":52,"context_line":"  just version of OpenStack, there should be only version number used, like"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1d9f36c1_7c8be3af","line":49,"in_reply_to":"2587f434_75910fba","updated":"2023-02-20 20:30:19.000000000","message":"Series is more inline with the maintenance model, as a serious issue may be discovered on a stable branch which requires an immediate release.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"2e1841778b15ba06531f0250424e45eba6562ff5","unresolved":true,"context_lines":[{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"},{"line_number":52,"context_line":"  just version of OpenStack, there should be only version number used, like"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2587f434_75910fba","line":49,"in_reply_to":"733fda28_8d1ad9fa","updated":"2023-02-20 19:47:36.000000000","message":"There ARE multiple versions of Nova/Neutron referred to by 2023.1. Every single stable release emitted during that cycle. We shoudn\u0027t treat \"2023.1\" as if it refers to a single release when that\u0027s simply not true over the life of a project. That\u0027s why the \"Series\" is added here.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"e7297bd85d01d8a4be97f791cc533c06890e6fcd","unresolved":true,"context_lines":[{"line_number":46,"context_line":"  Examples:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"  * Nova 2023.1 Series (27.0.0)"},{"line_number":49,"context_line":"  * Neutron 2023.2 Series (23.0.0)"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"  In case when there is no need to give version of the specific project, but"},{"line_number":52,"context_line":"  just version of OpenStack, there should be only version number used, like"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfbec06f_7c8d0d27","line":49,"in_reply_to":"97e7131b_cc1ab639","updated":"2023-02-27 16:42:46.000000000","message":"I think this writing makes sense in some contexts -- but I\u0027m not sure it\u0027s any more likely to garner majority support.\n\nOne thing important to remember is that we\u0027re not saying that projects with a non-integrated use case won\u0027t *ever* use the full integrated version, just that we want the projects to have the freedom to choose based on context.","commit_id":"0490ece2590082447edeed0ac458c3fb651aa297"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"0d7dfa14a7528dd65517029d839acaec594b387b","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"  * Nova 27.0.0"},{"line_number":66,"context_line":"  * Neutron 23.0.0"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* Project specific documentation: use release name combined with version of the project."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0ded8cba_04c279e3","line":67,"range":{"start_line":60,"start_character":0,"end_line":67,"end_character":0},"updated":"2023-02-20 20:09:35.000000000","message":"it seems you wrote this twice, it already added at L75","commit_id":"9ba5faefea68504866f5d45f7fae39f9c2901caf"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"429b5aa9a3e755eff109dc9e10dd9ec1df8fb4f4","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"  * Nova 27.0.0"},{"line_number":66,"context_line":"  * Neutron 23.0.0"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* Project specific documentation: use release name combined with version of the project."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"82fdabc2_16473ad2","line":67,"range":{"start_line":60,"start_character":0,"end_line":67,"end_character":0},"in_reply_to":"0ded8cba_04c279e3","updated":"2023-02-20 20:11:03.000000000","message":"These are two separate sections: one refers to guidelines for release notes, one refers to guidelines for project-specific documentation.","commit_id":"9ba5faefea68504866f5d45f7fae39f9c2901caf"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"644eb5af90abb3bbc748234ac2193454ae295888","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"  * Nova 27.0.0"},{"line_number":66,"context_line":"  * Neutron 23.0.0"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* Project specific documentation: use release name combined with version of the project."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2591ac36_d41e0be1","line":67,"range":{"start_line":60,"start_character":0,"end_line":67,"end_character":0},"in_reply_to":"82fdabc2_16473ad2","updated":"2023-02-20 20:12:29.000000000","message":"ah right, I overlooked the gerrit diff.","commit_id":"9ba5faefea68504866f5d45f7fae39f9c2901caf"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ca136439cb93f0abcaf9dab11cf6856a4f5a2ced","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f74c0594_234cb638","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"updated":"2023-02-20 20:18:23.000000000","message":"I understand what you mean here, but everything else in this document is instructive and not \"if you like, you can follow these guidelines.\" By using \"desire\" here you\u0027re leaving it up to whether or not the person wants to do things like this, IMHO. I think it would be better to cover your case with the specific reason of \"When there is no need to indicate the coordinated release, or for projects with strong standalone user bases, the coordinated release identification may be omitted\" with something more direct.\n\nAlthough I\u0027d like to point out that I don\u0027t think we\u0027re doing our users (and yes, I mean people that consider themselves \"OpenStack users\") any favors my crystallizing these barriers in between components they mostly see as a whole. Being so concerned about distancing/insulating itself from the OpenStack brand, it makes me wonder why Ironic even wants to be part of OpenStack at all.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"36c57fe875664d46c405abad5e1a17f303b13131","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b5af5693_a7056ea1","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"in_reply_to":"0166d7aa_c727441e","updated":"2023-02-20 21:08:41.000000000","message":"Right, I think the consistency is a much bigger win than the concern of someone stumbling onto Ironic docs (which are hosted on docs.openstack.org) and saying \"WAT? OpenStack? Too rich for my blood, I\u0027ll find something else.\"\n\nIf there is that concern, and ironic docs are also hosted elsewhere, then perhaps it would be worthwhile to have an alternate rendering of those docs without the OpenStack verbiage, or with different verbiage. However, disassociating Ironic from the 2023.1 release *increases* confusion to me. Both because it\u0027s different than Keystone, Nova, and Neutron, and because making the same change to those projects for consistency with ironic would arguably defeat the purpose of consistency with the rest of the projects and docs in our coordinated release.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"83af6f8e7b47e2a34542a514650efd20e5f5af8d","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"03bf50f7_a804bef2","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"in_reply_to":"516678ee_fdadca3e","updated":"2023-02-22 17:10:57.000000000","message":"I honestly think that mentioning the coordinated release overweights the small benefit of not mentioning openstack to the few consumers of a standalone project that don\u0027t know of OpenStack.\n\nWhile those consumers couldn\u0027t know that OpenStack exists, many other consumers of this standalone project would know that this project has been tested amongst a large set of other projects and that is guaranteeing that if they want to play with another project, it would work.\n\nI personnally think this is a strong incentive for using OpenStack despite the project is very clear of the fact it can be run on a standalone mode, so I feel that the very small confusion it may create for a few users is probably something that can be rather addressed by better project documentation about the possibility of being used standalone (and shouldn\u0027t be addressed by removing the existence of OpenStack in the release number)","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"2d18c48777be4c8b747a1421dd51edf7008d858a","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"516678ee_fdadca3e","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"in_reply_to":"b5af5693_a7056ea1","updated":"2023-02-22 01:09:59.000000000","message":"I would like to get a call scheduled to discuss this. We have many different perceptions at play which are inherently at odds. If we can have a sincere discussion where our perceptions and concerns are expressed, and we give a chance to everyone to try and reach the the same page, I strongly believe we will understand each other and we will organically reach an appropriate consensus or understanding.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9150029bad0f32b76393d7ee67ef7ed56fa99799","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"26ca41a0_acb9e32a","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"in_reply_to":"f1abcdd3_d0f7480d","updated":"2023-02-20 20:49:12.000000000","message":"\u003e I think you see this as building barriers between OpenStack projects; I see it as trying to build bridges into the OpenStack ecosystem using things like Ironic which are generally useful even for people who may not have heard of OpenStack. For every blogpost someone writes about kubernetes \u0027replacing\u0027 openstack or something similarly trite, there\u0027s a production environment combining pieces of both ecosystem to make things work. This is a strength; not a weakness! I can\u0027t be the only person who thinks it\u0027s amazing that we ship software that\u0027s useful when integrated together AND can be integrated with other pieces from other ecosystems as well?\n\nI _do_ see it as building barriers between OpenStack projects, and I simultaneously _do_ believe that many of our components should be reusable outside of \"a cloud of keystone, nova and neutron\", be it \"ironic operating standalone\" or any other project outside in our ecosystem. Straddling the gap between being an integrated part of the whole and a fully-standalone component involves additional costs, which could come in the form of users of the larger system being more confused, or the standalone projects having to do some additional work to exist in both camps. It was asserted that asking the standalone projects to do that would be unreasonable, and I\u0027m saying I think it\u0027s unreasonable to ask the other components of the whole system to pay into that in the form of less consistent docs, versioning, etc.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"7a75a738e5cc00fa14b4cc23df14ebdc56cb7850","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0166d7aa_c727441e","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"in_reply_to":"f1abcdd3_d0f7480d","updated":"2023-02-20 20:53:01.000000000","message":"Honestly saying, I am not sure why the argument of more or fewer users comparison is. OpenStack as a whole community and governance provides an umbrella of process/governance/guidelines/technical guidelines for consistency to all the projects under it. Considering each use case say integrated and standalone is good but keeping consistency among all the OpenStack projects matters a lot. \n\nWhy do we think OpenStack as a brand confuses users even from where it all started? If any users do not know about OpenStack and know only about the specific project then educating them and giving reference to how OpenStack play role in all the individual projects is the right thing to do. This does not mean users will hate the \u0027OpenStack\u0027 brand and go away when there is no difference in the actual process being followed by referencing the OpenStack or not referring to it.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1125c9c98265839771d72845810bfd10b7bbd9a4","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"38c76385_93727e80","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"in_reply_to":"f74c0594_234cb638","updated":"2023-02-20 20:21:24.000000000","message":"And I guess I\u0027d add that projects who simultaneously want to be part of the openstack project and distance themselves from it, may have to shoulder some of the additional weight involved in maintaining that distinction. Just like we would if they wanted to not use some of our core technical components and processes.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"881351202130c9e87665a919a90dd289bc0ec9b3","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  * OpenStack 2023.2"},{"line_number":58,"context_line":"  * OpenStack 2024.1"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"  In cases where there is no need or desire to indicate the coordinated release of the"},{"line_number":61,"context_line":"  specific project, it may be omitted entirely."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f1abcdd3_d0f7480d","line":60,"range":{"start_line":60,"start_character":37,"end_line":60,"end_character":43},"in_reply_to":"f74c0594_234cb638","updated":"2023-02-20 20:29:37.000000000","message":"This is where the perspective differences come in: OpenStack has many customers.\n\nOpenStack have customers who run more-or-less most of the integrated release. They see and use OpenStack as a single large software project that works together. We work great in that case! Ironic is a nice bare metal provisioning piece that slots right in alongside many other places.\n\nOpenStack also has customers who use our provided services and utilities more piecemeal. I\u0027m going to intentionally pick a non-Ironic example: diskimage-builder. diskimage-builder is used (and packaged) many more places than just in OpenStack -- for instance, gentoo packages diskimage-builder in their primary repo despite packaging few other OpenStack deliverables. Ironic has a larger number than most other OpenStack projects of users in this category, due to integrations with other stacks such as metal3.io.\n\n\nBoth of these groups are OpenStack users. Ironic standalone users /are openstack users/ even if they don\u0027t know it[1]. It\u0027s just a question of what they expect to see on the tin. I\u0027m extremely happy to have Ironic as a part of OpenStack, and have that used in things shipped as part of kubernetes and used for standalone cases like with bifrost (another OpenStack project!).\n\nI think you see this as building barriers between OpenStack projects; I see it as trying to build bridges into the OpenStack ecosystem using things like Ironic which are generally useful even for people who may not have heard of OpenStack. For every blogpost someone writes about kubernetes \u0027replacing\u0027 openstack or something similarly trite, there\u0027s a production environment combining pieces of both ecosystem to make things work. This is a strength; not a weakness! I can\u0027t be the only person who thinks it\u0027s amazing that we ship software that\u0027s useful when integrated together AND can be integrated with other pieces from other ecosystems as well? I am trying to make sure we remain careful about language to not scare people away with the bulk of all of OpenStack when they are maybe only ready for a piece of it.\n\n\n1: As a piece of anecdata; if you listen to the recorded version of ttx\u0027s talk from FOSDEM about OpenStack being successful; someone in the Q\u0026A mentions metal3 as an alternative to OpenStack, with no idea it\u0027s powered by Ironic. I don\u0027t want to confuse this type user when they go to view our release notes, or come to IRC to ask us questions.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"83af6f8e7b47e2a34542a514650efd20e5f5af8d","unresolved":true,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"  * Nova 27.0.0"},{"line_number":66,"context_line":"  * Neutron 23.0.0"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* Project specific documentation: use release name combined with version of the project."}],"source_content_type":"text/x-rst","patch_set":3,"id":"f6c92b3f_bb99e18c","line":65,"updated":"2023-02-22 17:10:57.000000000","message":"Honestly, except the openstack/releases patches, that nova-specfic number seems meaningless for a lot of nova consumers. Most of our internals refer to the release name and none of the knobs we have ask for a release number.\n\nThe only case where we care of that number is for stable releases, in terms of semvers, to address the difference between a small z-release and a larger -y release.\n\nThis could be addressed with us saying \"nova 2023.1.0.0\" for describing the nova release matching antelope and \"nova 2023.1.0.1\" to mention the first stable release of antelope.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"be0f9a2f6c27088f3f5093f0784c601cc2ab8ebd","unresolved":true,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"  * Nova 27.0.0"},{"line_number":66,"context_line":"  * Neutron 23.0.0"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* Project specific documentation: use release name combined with version of the project."}],"source_content_type":"text/x-rst","patch_set":3,"id":"4911de29_0d3e7df7","line":65,"in_reply_to":"6c4ef447_79d8ee1f","updated":"2023-02-23 16:03:12.000000000","message":"\u003e \u003e nova 2023.1.0.0\n\u003e \n\u003e I don\u0027t think you can do that according to PEP 440 - there are quite some rules that must be met when talking about versioning and I don\u0027t think we should use arbitrary versions naming to be frank.\n\u003e That will also close us way back to usage of semantic versions as date-based ones are always treated as newer ones.\n\u003e \n\nOh I oversimplified for the sake of saying that I\u0027d prefer our nova packages be using the overall OpenStack version number instead of some meaningless indicator (please count how many times we released this service project compared to the others).\n\nI didn\u0027t want to reopen wounds, but if we were about semantic versioning while agreeing on stopping to have a project-specific number, then for a second, I\u0027d bikeshed with openstack-nova.2023.1.0.0 or openstack-nova-20231.0.0 if we do \n\n\nThere we go. I just opened the can, sorry.\n\n\u003e Also I don\u0027t agree that nobody cares about nova versions. At least it not the case among operators I talked to. As once shit hits the fan first thing you go and check - what actual nova version you\u0027re running in order to compare codebase and check for release notes if any bugs were fixed in the meanwhile. It\u0027s good to know that you\u0027re running Zed, but in day2 you often circle back to pip freeze output, unless you\u0027re following branch HEAD.\n\u003e Next example are secops, that always want to know what exact version of service is running to be able to verify if it\u0027s vulnerable to some OSSA or not.\n\u003e And ofc bug reporting and debugging. The first thing you need to supply is nova version and without this information I\u0027m not sure how it\u0027s possible to triage things, unless it\u0027s a project with really not a lot of patches on stable branches.\n\u003e \n\u003e IMO openstack version should be mentioned and is valuable, but after day0 you\u0027re more interested in what you\u0027re actually running.\n\nIf it\u0027s a pip or rpm issue, wouldn\u0027t that be easier for ops to have a shared digit for each of the packages that compose their environment which would indicate they\u0027re compatible with ?","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"df03c881c5af34b43b36ffd66469024245c85166","unresolved":true,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"  * Nova 27.0.0"},{"line_number":66,"context_line":"  * Neutron 23.0.0"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* Project specific documentation: use release name combined with version of the project."}],"source_content_type":"text/x-rst","patch_set":3,"id":"94d07e6b_21929dcc","line":65,"in_reply_to":"6c4ef447_79d8ee1f","updated":"2023-02-23 16:15:09.000000000","message":"\u003e I don\u0027t think you can do that according to PEP 440 - there are quite some rules that must be met when talking about versioning and I don\u0027t think we should use arbitrary versions naming to be frank.\n\u003e That will also close us way back to usage of semantic versions as date-based ones are always treated as newer ones.\n\nAFAIK, 2023.1.0 is a valid PEP440 version number (i.e. we might have to drop the fourth segment from what Sylvain suggested). But we could still make that work.\n\nI find it incredibly frustrating that the python people have decided to enforce version number formats to that level of detail, as it is causing a lot of problems for people, but I digress.\n\n\u003e Also I don\u0027t agree that nobody cares about nova versions. At least it not the case among operators I talked to. As once shit hits the fan first thing you go and check - what actual nova version you\u0027re running in order to compare codebase and check for release notes if any bugs were fixed in the meanwhile. It\u0027s good to know that you\u0027re running Zed, but in day2 you often circle back to pip freeze output, unless you\u0027re following branch HEAD.\n\u003e Next example are secops, that always want to know what exact version of service is running to be able to verify if it\u0027s vulnerable to some OSSA or not.\n\u003e And ofc bug reporting and debugging. The first thing you need to supply is nova version and without this information I\u0027m not sure how it\u0027s possible to triage things, unless it\u0027s a project with really not a lot of patches on stable branches.\n\nYeah, I don\u0027t think he meant that it\u0027s not important. It\u0027s important like git hashes are important, it\u0027s just not very symbolically useful, and hard to remember since it differs for every project in a given release.\n\n\u003e IMO openstack version should be mentioned and is valuable, but after day0 you\u0027re more interested in what you\u0027re actually running.\n\nAgree. I also agree with Sylvain that seeing 2023.1.x for all the related openstack packages in your `pip freeze` would be very nice. Sure you still need to check the `.x` to make sure you\u0027re up to date with individual packages, but it would be massively easier to find a package that got skipped, accidentally upgraded, etc. That\u0027s not really the subject of this change, so we should probably discuss further elsewhere, but I *do* think that would be a welcome change, from my perspective, and would cut down on a lot of actual legit inconsistency.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"e5e2412acc3184c9887491ca2ed3839196acc953","unresolved":true,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"  Examples:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"  * Nova 27.0.0"},{"line_number":66,"context_line":"  * Neutron 23.0.0"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* Project specific documentation: use release name combined with version of the project."}],"source_content_type":"text/x-rst","patch_set":3,"id":"6c4ef447_79d8ee1f","line":65,"in_reply_to":"f6c92b3f_bb99e18c","updated":"2023-02-23 08:08:10.000000000","message":"\u003e nova 2023.1.0.0\n\nI don\u0027t think you can do that according to PEP 440 - there are quite some rules that must be met when talking about versioning and I don\u0027t think we should use arbitrary versions naming to be frank.\nThat will also close us way back to usage of semantic versions as date-based ones are always treated as newer ones.\n\nAlso I don\u0027t agree that nobody cares about nova versions. At least it not the case among operators I talked to. As once shit hits the fan first thing you go and check - what actual nova version you\u0027re running in order to compare codebase and check for release notes if any bugs were fixed in the meanwhile. It\u0027s good to know that you\u0027re running Zed, but in day2 you often circle back to pip freeze output, unless you\u0027re following branch HEAD.\nNext example are secops, that always want to know what exact version of service is running to be able to verify if it\u0027s vulnerable to some OSSA or not.\nAnd ofc bug reporting and debugging. The first thing you need to supply is nova version and without this information I\u0027m not sure how it\u0027s possible to triage things, unless it\u0027s a project with really not a lot of patches on stable branches.\n\nIMO openstack version should be mentioned and is valuable, but after day0 you\u0027re more interested in what you\u0027re actually running.","commit_id":"15419e0e441304c28e473128aa6e903e7a5555bb"}]}