| *** diablo_rojo is now known as Guest1719 | 04:01 | |
| *** amoralej|off is now known as amoralej | 07:28 | |
| elodilles | reminder: weekly meeting in 10 mins | 13:49 |
|---|---|---|
| hberaud | damani: FYI ^ | 13:58 |
| elodilles | it's time! | 14:00 |
| elodilles | let's start | 14:00 |
| elodilles | #startmeeting releaseteam | 14:01 |
| opendevmeet | Meeting started Fri Feb 4 14:01:14 2022 UTC and is due to finish in 60 minutes. The chair is elodilles. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'releaseteam' | 14:01 |
| hberaud | o/ | 14:01 |
| elodilles | Ping list: hberaud ttx armstrong | 14:01 |
| elodilles | o/ | 14:01 |
| elodilles | https://etherpad.opendev.org/p/yoga-relmgt-tracking | 14:01 |
| elodilles | i mean | 14:02 |
| damani | hi | 14:02 |
| elodilles | #link https://etherpad.opendev.org/p/yoga-relmgt-tracking | 14:02 |
| ttx | o/ | 14:02 |
| elodilles | we are way down around line 231 | 14:02 |
| diablo_rojo_phone | o/ | 14:03 |
| elodilles | so nice to see so many participants :) | 14:03 |
| elodilles | let's start with the 1st topic | 14:04 |
| elodilles | #topic Review task completion | 14:04 |
| elodilles | there was only 1 task for the week (beyond the countdown mail one): | 14:05 |
| elodilles | * Make sure the next development series name has been added to the data/series_status.yaml file (elod) | 14:05 |
| elodilles | so far the next release name is not announced yet, | 14:06 |
| elodilles | and if i'm not mistaken that is needed for this task | 14:06 |
| elodilles | so this needs a follow up | 14:07 |
| hberaud | yes | 14:07 |
| elodilles | #action (elod) Make sure the next development series name has been added to data/series_status.yaml, when it is announced | 14:08 |
| elodilles | ^^^ | 14:08 |
| hberaud | also we could move it to the next meeting agenda | 14:09 |
| hberaud | just in case | 14:09 |
| elodilles | good idea, i've added it to 'next week tasks' | 14:10 |
| ttx | Hopefully should have a name validated in < 2 weeks | 14:10 |
| diablo_rojo_phone | We should have the name in the next week or so | 14:10 |
| elodilles | fingers crossed :] | 14:10 |
| diablo_rojo_phone | lol jinx :) | 14:10 |
| elodilles | good. i think we can move on | 14:10 |
| elodilles | #topic Assign R-7 week tasks | 14:11 |
| elodilles | ttx volunteered for the 1st task as i see: Review Skyline ACL settings | 14:11 |
| ttx | yep, with the repo transitioned and all we are ready to fix acl there | 14:12 |
| elodilles | cool | 14:12 |
| elodilles | any volunteer for this one? 'Notify the Infrastructure team to generate an artifact signing key (but not replace the current one yet), and begin the attestation process.' | 14:12 |
| diablo_rojo_phone | I can do it | 14:13 |
| diablo_rojo_phone | Added my name there | 14:13 |
| elodilles | diablo_rojo_phone: thanks \o/ | 14:13 |
| elodilles | hberaud took the 3rd task: Check with the Technical Committee to make sure Python runtimes have been determined for the next development cycle and that Zuul job templates have been created to include those runtimes | 14:14 |
| elodilles | thanks! | 14:14 |
| damani | i can work work hberaud | 14:14 |
| hberaud | you're welcome | 14:14 |
| elodilles | and the follow-up we discussed above + countdown mail are on me | 14:14 |
| damani | with | 14:14 |
| hberaud | damani: sure | 14:15 |
| elodilles | damani hberaud : even better, thanks! :] | 14:15 |
| hberaud | damani: when are you available next week? | 14:15 |
| damani | tuesday ? | 14:15 |
| damani | or monday morning | 14:15 |
| hberaud | I prefer monday morning | 14:16 |
| damani | ok | 14:16 |
| damani | let's go for monday morning :) | 14:16 |
| hberaud | let me ping you in the middle of the morning | 14:16 |
| hberaud | thanks damani! | 14:16 |
| damani | hberaud, you're welcome :) | 14:17 |
| elodilles | nice :) so we are done with this topic | 14:17 |
| elodilles | next one: | 14:17 |
| elodilles | #topic Review countdown email contents | 14:18 |
| elodilles | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:18 |
| elodilles | please review ^^^ | 14:18 |
| elodilles | is March 24th the final rc deadline? | 14:20 |
| hberaud | yes | 14:21 |
| hberaud | LGTM | 14:21 |
| ttx | lgtm | 14:21 |
| elodilles | awesome, thanks! I'll send it some time after the meeting | 14:22 |
| elodilles | move on to the final topic: | 14:22 |
| elodilles | #topic Open Discussion | 14:22 |
| elodilles | rosmaita added a point here: 'I have a question about what to do about a crazy glance test that is related to the release major version' | 14:23 |
| elodilles | rosmaita: if you are around ^^^ | 14:23 |
| rosmaita | o/ | 14:23 |
| rosmaita | yeah, the info is on the agenda | 14:24 |
| rosmaita | we have a situation where the way we set up database migrations requires a constant that indicates the current release name | 14:24 |
| rosmaita | and if we forget to update, the migrations don't work | 14:25 |
| rosmaita | which happened once | 14:25 |
| rosmaita | so we have a test that will break horribly if the release name constant and the release number are not in sync | 14:25 |
| rosmaita | but the problem is that the way it works is you have to do: release a yoga milestone, break the test, fix the test, and we are ok until next cycle | 14:26 |
| rosmaita | that worked ok when we were required to release milestones | 14:26 |
| rosmaita | because we would get this done at M-1 | 14:26 |
| rosmaita | but, now we are looking at RC-time, which is not good | 14:26 |
| ttx | you can still do milestone release any time | 14:26 |
| rosmaita | yeah, but i was wondering if we can just do Sem-Ver on a patch instead | 14:27 |
| rosmaita | or, not have this stupid test at all | 14:27 |
| ttx | Not sure I understand what you mean by "do Sem-Ver on a patch instead" | 14:28 |
| fungi | could the test be made to accept a newer migration than the current software version, rather than an exact match? | 14:28 |
| rosmaita | is there a reason why the Sem-Ver patch the release team posts to master after the stable branch is cut (the one with the releasenotes new index files) only increments the feature number in master? | 14:28 |
| rosmaita | i've seen "Sem-Ver: feature", is there "Sem-Ver: major" or something like that? | 14:29 |
| fungi | checked the pbr docs? | 14:30 |
| rosmaita | i did, but not thoroughly enough | 14:30 |
| rosmaita | i guess one question is that when you increment the version number in master, it goes from 19.0 -> 19.1 ... is there a reason why we don't just go 19.0 -> 20.0 ? | 14:31 |
| ttx | For intermediary-released things we need to do at least a feature bump, whioch is probably why that's done here | 14:32 |
| rosmaita | and fungi, i think making the test accept current or later may be ok | 14:32 |
| ttx | but yeah, for cycle-with-rc things we do a major jump anyway | 14:32 |
| fungi | "The following symbols are recognized: feature, api-break, deprecation, bugfix [...] The api-break symbol causes a major version increment." https://docs.openstack.org/pbr/latest/user/features.html#package-metadata | 14:32 |
| rosmaita | ttx: "at least" ... so would a major bump be ok | 14:32 |
| rosmaita | i can just see people freak out when i post a patch that says "api-break" :) | 14:33 |
| elodilles | :) | 14:33 |
| ttx | rosmaita: I bet cycle-with-intermediary deliverables would complain if you bumped their major. But we could maybe generate different patches for cycle-with-rc things | 14:33 |
| fungi | rosmaita: you could propose an alias for it in pbr, right now feature and deprecation have identical behavior, for example | 14:34 |
| ttx | I'm not sure where the code that produces that patch is located | 14:34 |
| rosmaita | that's ok, i was joking | 14:34 |
| fungi | so there's precedent for having multiple terms for the same behavior | 14:34 |
| rosmaita | we can do this as a one-off for glance, no need to revise it for everyone else | 14:35 |
| rosmaita | our problem will go away during Z anyway, as the db migration code needs to be refactored | 14:35 |
| ttx | I'm ok with trying it in master Z opening | 14:35 |
| ttx | we might need to remember to amend the patch though | 14:36 |
| rosmaita | so, to summarize: i can solve our problem for this current cycle by posting a patch with "Sem-Ver: api-break" | 14:36 |
| rosmaita | that will bump the version for glance | 14:36 |
| rosmaita | break the test, and then we update the constant | 14:37 |
| rosmaita | thanks! | 14:37 |
| ttx | then we need to wait until the "Update master for stable/yoga" patch is posted, and remember that it should be amended to api-break before being approved | 14:37 |
| fungi | rosmaita: it's possible that the patch with "Sem-Ver: api-break" could be the patch which increments the migration serial | 14:37 |
| fungi | (might even be necessary that they be the same patch) | 14:38 |
| elodilles | good, thanks, so this can be handled like rosmaita said above for this cycle and next cycle the problem will be gone as far as i understand | 14:40 |
| rosmaita | fungi: i think the problem is that the test will fail so the patch incrementing the version can't land | 14:40 |
| rosmaita | but we will think carefully | 14:40 |
| rosmaita | elodilles: yes, that's right | 14:40 |
| rosmaita | thanks, everyone! | 14:40 |
| fungi | rosmaita: right, i'm thinking the test change and the version increment might need to be the same patch so that the test passes the change | 14:41 |
| fungi | but yeah, that doesn't need to be solved in the release meeting | 14:41 |
| rosmaita | :0 | 14:42 |
| elodilles | maybe this is one thing (to update the reno-* patch generation) to the 'things to change' list? | 14:42 |
| elodilles | i mean to add 'Sem-Ver: api-break' for rc deliverables (and leave 'feature' for cwi deliverables) | 14:43 |
| elodilles | in case someone else needs it | 14:43 |
| elodilles | do you see others with the same problem? is it worth to add this? | 14:44 |
| fungi | the main downside is you can't really unwind those commit message hints, so if a project wanted to switch release models after the release, they'd be stuck with a major version bump for their next intermediate from master | 14:44 |
| elodilles | fungi: hmm, that sounds logical | 14:44 |
| fungi | not a show-stopper, but it could be inconvenient/confusing | 14:45 |
| elodilles | so then it is OK how it is now... or at least, less painful, in case of a release model change | 14:45 |
| elodilles | good, thanks | 14:46 |
| elodilles | any other topic? anyone? | 14:46 |
| ttx | nope | 14:47 |
| elodilles | hmmm, sorry, i found one: https://review.opendev.org/q/topic:not-yet-released-yoga | 14:47 |
| elodilles | so the release model changing patches can be mostly abandoned | 14:48 |
| elodilles | i mean, except | 14:48 |
| elodilles | ovn-octavia-provider | 14:48 |
| elodilles | as neutron is OK with the change | 14:48 |
| elodilles | any comment for this? | 14:49 |
| hberaud | nope | 14:49 |
| elodilles | (sorry, this was a task from last week and the deadline is today) | 14:49 |
| elodilles | hberaud: ack, thanks :) | 14:50 |
| ttx | works for me | 14:50 |
| elodilles | ++ | 14:50 |
| hberaud | +1 | 14:50 |
| elodilles | if there is nothing else then let's close the meeting | 14:51 |
| hberaud | nope | 14:51 |
| diablo_rojo_phone | None from me | 14:51 |
| elodilles | thanks everyone for joining! | 14:51 |
| hberaud | Thanks elodilles | 14:52 |
| elodilles | #endmeeting | 14:52 |
| opendevmeet | Meeting ended Fri Feb 4 14:52:17 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:52 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-02-04-14.01.html | 14:52 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-02-04-14.01.txt | 14:52 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-02-04-14.01.log.html | 14:52 |
| ttx | thanks elodilles ! | 14:52 |
| armstrong | thx elodilles | 14:54 |
| elodilles | o/ | 14:54 |
| elodilles | damani: if you want to be pinged for the release meeting when it starts then you can add your name to the 'Ping list' in the tracking etherpad | 14:57 |
| damani | elodilles, yes, i will do it | 15:03 |
| elodilles | :] | 15:21 |
| *** marios is now known as marios|out | 16:38 | |
| opendevreview | Merged openstack/releases master: [ovn-octavia-provider] Propose to switch the release model https://review.opendev.org/c/openstack/releases/+/826331 | 17:08 |
| *** amoralej is now known as amoralej|off | 17:41 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!