| *** spotz__ is now known as spotz_ | 13:51 | |
| pmatulis2 | re release name changes, i see that this main doc index is devoid of content. has there been a mixup somewhere? | 14:10 |
|---|---|---|
| pmatulis2 | https://docs.openstack.org/2023.1.antelope/user/ | 14:11 |
| clarkb | pmatulis2: the index is built dynamically inspecting attributes https://opendev.org/openstack/openstack-manuals/src/branch/master/www/2023.1.antelope/user/index.html#L41-L50 I'm going to guess they haven't been written yet maybe? | 14:29 |
| clarkb | or possibly a bug in those lookups | 14:30 |
| fungi | pmatulis2: i suspect it has to do with the user guides being at urls like https://docs.openstack.org/nova/2023.1/user/ instead of https://docs.openstack.org/nova/2023.1.antelope/user/ | 14:30 |
| clarkb | https://opendev.org/openstack/openstack-manuals/src/branch/master/tools/www-generator.py#L262-L427 appears to be the code that generates the projects iterable | 14:31 |
| *** pmatulis2 is now known as pmatulis | 16:14 | |
| opendevreview | James Slagle proposed openstack/governance master: TripleO: switch to distributed project leadership https://review.opendev.org/c/openstack/governance/+/878799 | 16:45 |
| bauzas | rosmaita: hello, we discussed about the SLURP cadence in the nova room today and I was wondering how we could continue to provide release notes from Bobcat in C in case they were for deprecations and removes https://etherpad.opendev.org/p/nova-bobcat-ptg#L300 | 18:54 |
| bauzas | rosmaita: so I was wondering if reno was able to find a way to say "this note can be needed for the current master branch but should also be used for the 'next' branch' | 18:55 |
| bauzas | and dansmith told me that you were trying to help about that | 18:56 |
| rosmaita | bauzas: this is the basic idea: https://review.opendev.org/c/openstack/project-team-guide/+/843457/1/doc/source/release-management.rst | 19:00 |
| bauzas | rosmaita: ok, so you would provide a symlink from the previous cycle ? | 19:03 |
| bauzas | so operators would need to look at *all* the relnotes from Bobcat before they upgrade from Antelope to C ? | 19:04 |
| bauzas | well, I'm bit sad of that, because they should rather just look at the upgrades section IMHO | 19:05 |
| rosmaita | two ways to look at it: if there's nothing happening in slurp-1, then the notes are short anyway; and if there's a lot going on, this way there's an easy reference | 19:06 |
| bauzas | ok, I'm saying it because I'd prefer to just ask to punt deprecations and removes only on SLURP releases | 19:07 |
| bauzas | defer* rather than punt | 19:08 |
| dansmith | bauzas: there's also the issue of new features added in a non-SLURP release | 19:08 |
| dansmith | but you already know I think it's easier to save deprecation/removal for SLURPs to that at least there are only a few things needing to be brought forward to the SLURP renos | 19:09 |
| dansmith | users would forgive us if they miss a new feature or bugfix mention, but probably not so much a deprecation/removal :) | 19:09 |
| bauzas | dansmith: sure, for features I understand we could provide a link | 19:11 |
| bauzas | honestly, I wonder whether we should rather have two relnotes for C, one for a B->C upgrade and the other one for a SLURP upgrade | 19:12 |
| bauzas | so we would just mix all the relnotes from B and C in the same doc | 19:12 |
| bauzas | simplier for ops | 19:12 |
| bauzas | like, you upgrade from B to C > this | 19:13 |
| bauzas | you upgrade from A to C > that | 19:13 |
| gmann | but A->C things are superset of B-C right? | 19:13 |
| bauzas | yes | 19:14 |
| JayF | Anything that curates a subset of reviews from A for SLURP upgraders from A->C would be tacitly encouraging operators to upgrade without reading all release notes, yeah? | 19:14 |
| gmann | which is nothing but A->C = A->B + B->C | 19:14 |
| JayF | I think gmann and I are on the same wavelength :) | 19:14 |
| bauzas | we would then have two different links | 19:15 |
| JayF | It might be wise to advise projects to link to the SLURP-first-half release release notes in the SLURP-second-half release notes prelude | 19:15 |
| bauzas | if people want to read A>B and then B>C instead of reading directly A>C, that's fair | 19:15 |
| gmann | A->C directly is preferred for A->C upgrade right but I am saying having two section for those two upgrade might confuse or may be better? need to see how it will looks like | 19:16 |
| bauzas | gmann: we could try to collapse both upgrade sections (for B and C) into one reported section only | 19:19 |
| JayF | Is it possible to do that in a way that won't make it more confusing for people upgrading on a 6 month cadence? | 19:19 |
| JayF | We'd almost need to indicate it's a repeat for SLURP upgraders only | 19:19 |
| bauzas | looks to me reno doesn't support it yet but already supports a 'collapse-pre-releases' tag for sphinx | 19:19 |
| bauzas | https://docs.openstack.org/reno/latest/user/sphinxext.html#directive-release-notes | 19:19 |
| bauzas | JayF: if we have two documents, one for B>C and the other one for A>C, operators wouldn't be confused I guess | 19:20 |
| gmann | yeah, that will be good. and I think any one upgrading 6 month will see any repeat upgrade notes will be 'ok I have already taken care of it in my previous upgrade' should be ok for them | 19:20 |
| bauzas | they would read the releated document from where they were to where they are | 19:20 |
| JayF | Yeah, there are a few options, one would be "separate SLURP release notes", one is "link 'A' release notes from 'B' release notes and trust operators to read both", and there are mixes of approaches (like collapsing together deprecations/upgrades with a notice) | 19:21 |
| bauzas | I just don't want to hijack too much openstack-specific sugar syntax into reno | 19:22 |
| JayF | That kind of approach, trusting operators to not re-do deprecation preparations because they should just know they already did it, could be applied in reverse: operators upgrading two-releases-in-one should know that and just read both sets of notes | 19:22 |
| bauzas | that would be terrible to ask the reno devs to have some tag that'd say 'this is a SLURP release' IMO | 19:22 |
| JayF | Yeah. That's why my suggestion was to keep it as simple as possible: a note in the prelude for SLURP releases to go read the previous releases' notes if you're doing a SLURP upgrade. | 19:23 |
| JayF | (preferably with a link) | 19:23 |
| bauzas | Well, I experienced this with Fedora | 19:23 |
| bauzas | and I don't like it | 19:23 |
| bauzas | I'd prefer to stack all the upgrade notes into one | 19:23 |
| bauzas | particularly if I'm committed to upgrade from a release to a N+x release without way of returning back | 19:24 |
| gmann | that will be easy | 19:24 |
| JayF | To serve both categories of operators at a high level, we'd need to publish two documents or have something dynamic :) | 19:24 |
| bauzas | JayF: hence me proposing to add *another* document besides the existing one https://docs.openstack.org/releasenotes/nova/2023.1.html | 19:25 |
| bauzas | instead of a flat list of symlinks in https://docs.openstack.org/releasenotes/nova/index.html | 19:25 |
| gmann | I think let's discuss it in TC slots and also how rosmaita idea and the new one looks like. | 19:26 |
| gmann | my brain is almost stopped working/thinking :) | 19:26 |
| bauzas | yeah no worries | 19:26 |
| JayF | Yeah, I missed that bauzas was talking about a different doc too. It's right in the wheelhouse of my working hours but brain is on PTG+Video meeting overload | 19:26 |
| bauzas | it's also 9pm26 for me and my wife is giving me bad eyesights :p | 19:27 |
| JayF | TC sessions is a good place for this | 19:27 |
| gmann | bauzas: :) | 19:27 |
| bauzas | JayF: I can try to attend those sessions but I'll need to ask someone else to chair the nova room then | 19:27 |
| bauzas | actually I'd love to | 19:28 |
| bauzas | and maybe I'm wrong, maybe thats a terrible way of reading notes | 19:28 |
| JayF | I'd say if we get an item in the TC agenda for it, you can also put your comments in the etherpad | 19:28 |
| JayF | if you can't attend personally | 19:28 |
| gmann | bauzas: after nova sessions, after 17 UTC ? | 19:28 |
| JayF | we shouldn't be making binding decisions in sync meeting anyway :) | 19:28 |
| bauzas | I just want to avoid *someone* to scrub the existing B notes to forward-port them into the C relnotes | 19:28 |
| gmann | if not too late for you | 19:28 |
| bauzas | gmann: ah right, this is only conflicting on Friday then | 19:29 |
| gmann | yeah | 19:29 |
| bauzas | if so, I can attend | 19:29 |
| bauzas | my beer keg isn't empty yet | 19:29 |
| bauzas | I just filled it in before the vPTG on Monday | 19:29 |
| gmann | thursday or friday I think we have some space after 17 UTC knikolla ? | 19:29 |
| bauzas | do we have other projects that discuss the SLURP cadence and the relnotes implications ? | 19:30 |
| bauzas | at least does the TC know of any ? | 19:30 |
| gmann | bauzas: not yet, cinder did last time where rosmaita started some ideas around it | 19:31 |
| bauzas | ack | 19:34 |
| gmann | bauzas: JayF added it in etherpad https://etherpad.opendev.org/p/tc-2023-2-ptg#L72 | 19:36 |
| JayF | I mean, I'm generally concerned with my Ironic hat on, but I don't think it was something we'd considered needing to be handled beyond mentioning it in release notes prelude | 19:37 |
| bauzas | gmann: JayF: all cool | 19:41 |
| knikolla | I’m away from computer right now, will read back for context and add the item to the agenda when I’m back. | 19:42 |
| *** JayF is now known as Guest9308 | 19:44 | |
| *** JasonF is now known as jayf | 19:44 | |
| *** jayf is now known as JayF | 19:44 | |
| gmann | knikolla: added it in thursday slot but you can check you want to fit it in thursday or friday 17 UTC ? | 19:57 |
| fungi | still catching up, but for the slurp releases why not just run reno twice and concatenate the output, so that the 2024.1 release notes contain a 2024.1 section and a 2023.2 section, while the 2023.2 release notes just have the 2023.2 section? might not need any changes to reno at all, just how it's run in the publishing job | 20:06 |
| fungi | maybe don't even need to run reno any differently, just have an extra collating step after reno runs to cram a copy of n-1 notes onto the end of the n notes for slurp releases | 20:07 |
| fungi | that prevents needing to maintain extra versions of release notes depending on whether the user is upgrading from the previous normal release or the previous slurp release, since if they're doing the former they can simply ignore the non-slurp notes in the second half of the document | 20:09 |
| fungi | it seems reasonable to expect them to at least know what version they were running and are upgrading from, such that seeing a section of release notes for a version they were already running can obviously be ignored | 20:12 |
| JayF | That becomes a more fraught question when you ask if a user is running OpenStack 2023.1 Ironic or OpenStack 2023.2 Ironic when pip freeze might say they're running 21.4.0 :) | 20:13 |
| fungi | https://docs.openstack.org/releasenotes/ironic/2023.1.html seems to list both | 20:25 |
| JayF | Fair | 20:25 |
| fungi | though it's unclear to me what that 21.4.0-5 version is | 20:26 |
| JayF | That is how prerelease changes show | 20:26 |
| JayF | e.g. those are the release notes for the current state of stable/2023.1 | 20:26 |
| JayF | that is yet-to-be-released | 20:27 |
| fungi | oh, right the -5 is the patch count | 20:27 |
| fungi | i thought at one point we were going to just make that heading say "unreleased changes" but i guess that didn't happen or was undone for a reason | 20:28 |
| knikolla | gmann: fully caught up on reading the IRC discussion. Thursday sounds better, so I left it where you put it. Thanks. | 21:02 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!