14:01:14 <elodilles> #startmeeting releaseteam
14:01:14 <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:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:14 <opendevmeet> The meeting name has been set to 'releaseteam'
14:01:21 <hberaud> o/
14:01:26 <elodilles> Ping list: hberaud ttx armstrong
14:01:32 <elodilles> o/
14:01:49 <elodilles> https://etherpad.opendev.org/p/yoga-relmgt-tracking
14:02:00 <elodilles> i mean
14:02:12 <damani> hi
14:02:15 <elodilles> #link https://etherpad.opendev.org/p/yoga-relmgt-tracking
14:02:19 <ttx> o/
14:02:48 <elodilles> we are way down around line 231
14:03:04 <diablo_rojo_phone> o/
14:03:48 <elodilles> so nice to see so many participants :)
14:04:12 <elodilles> let's start with the 1st topic
14:04:30 <elodilles> #topic Review task completion
14:05:37 <elodilles> there was only 1 task for the week (beyond the countdown mail one):
14:05:45 <elodilles> * Make sure the next development series name has been added to the data/series_status.yaml file (elod)
14:06:19 <elodilles> so far the next release name is not announced yet,
14:06:52 <elodilles> and if i'm not mistaken that is needed for this task
14:07:12 <elodilles> so this needs a follow up
14:07:23 <hberaud> yes
14:08:36 <elodilles> #action (elod) Make sure the next development series name has been added to data/series_status.yaml, when it is announced
14:08:40 <elodilles> ^^^
14:09:07 <hberaud> also we could move it to the next meeting agenda
14:09:24 <hberaud> just in case
14:10:09 <elodilles> good idea, i've added it to 'next week tasks'
14:10:12 <ttx> Hopefully should have a name validated in < 2 weeks
14:10:23 <diablo_rojo_phone> We should have the name in the next week or so
14:10:23 <elodilles> fingers crossed :]
14:10:32 <diablo_rojo_phone> lol jinx :)
14:10:56 <elodilles> good. i think we can move on
14:11:08 <elodilles> #topic Assign R-7 week tasks
14:11:39 <elodilles> ttx volunteered for the 1st task as i see: Review Skyline ACL settings
14:12:03 <ttx> yep, with the repo transitioned and all we are ready to fix acl there
14:12:29 <elodilles> cool
14:12:50 <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:13:02 <diablo_rojo_phone> I can do it
14:13:39 <diablo_rojo_phone> Added my name there
14:13:46 <elodilles> diablo_rojo_phone: thanks \o/
14:14:19 <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:23 <elodilles> thanks!
14:14:42 <damani> i can work work hberaud
14:14:46 <hberaud> you're welcome
14:14:57 <elodilles> and the follow-up we discussed above + countdown mail are on me
14:14:59 <damani> with
14:15:00 <hberaud> damani: sure
14:15:13 <elodilles> damani hberaud : even better, thanks! :]
14:15:25 <hberaud> damani: when are you available next week?
14:15:46 <damani> tuesday ?
14:15:53 <damani> or monday morning
14:16:03 <hberaud> I prefer monday morning
14:16:06 <damani> ok
14:16:19 <damani> let's go for monday morning :)
14:16:22 <hberaud> let me ping you in the middle of the morning
14:16:30 <hberaud> thanks damani!
14:17:18 <damani> hberaud, you're welcome :)
14:17:45 <elodilles> nice :) so we are done with this topic
14:17:50 <elodilles> next one:
14:18:08 <elodilles> #topic Review countdown email contents
14:18:22 <elodilles> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails
14:18:44 <elodilles> please review ^^^
14:20:05 <elodilles> is March 24th the final rc deadline?
14:21:11 <hberaud> yes
14:21:25 <hberaud> LGTM
14:21:47 <ttx> lgtm
14:22:14 <elodilles> awesome, thanks! I'll send it some time after the meeting
14:22:43 <elodilles> move on to the final topic:
14:22:49 <elodilles> #topic Open Discussion
14:23:26 <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:33 <elodilles> rosmaita: if you are around ^^^
14:23:57 <rosmaita> o/
14:24:31 <rosmaita> yeah, the info is on the agenda
14:24:57 <rosmaita> we have a situation where the way we set up database migrations requires a constant that indicates the current release name
14:25:06 <rosmaita> and if we forget to update, the migrations don't work
14:25:09 <rosmaita> which happened once
14:25:30 <rosmaita> so we have a test that will break horribly if the release name constant and the release number are not in sync
14:26:10 <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:27 <rosmaita> that worked ok when we were required to release milestones
14:26:34 <rosmaita> because we would get this done at M-1
14:26:47 <rosmaita> but, now we are looking at RC-time, which is not good
14:26:58 <ttx> you can still do milestone release any time
14:27:18 <rosmaita> yeah, but i was wondering if we can just do Sem-Ver on a patch instead
14:27:33 <rosmaita> or, not have this stupid test at all
14:28:25 <ttx> Not sure I understand what you mean by "do Sem-Ver on a patch instead"
14:28:55 <fungi> could the test be made to accept a newer migration than the current software version, rather than an exact match?
14:28:59 <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:29:50 <rosmaita> i've seen "Sem-Ver: feature", is there "Sem-Ver: major" or something like that?
14:30:13 <fungi> checked the pbr docs?
14:30:36 <rosmaita> i did, but not thoroughly enough
14:31:41 <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:32:25 <ttx> For intermediary-released things we need to do at least a feature bump, whioch is probably why that's done here
14:32:34 <rosmaita> and fungi, i think making the test accept current or later may be ok
14:32:46 <ttx> but yeah, for cycle-with-rc things we do a major jump anyway
14:32:48 <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:51 <rosmaita> ttx: "at least" ... so would a major bump be ok
14:33:25 <rosmaita> i can just see people freak out when i post a patch that says "api-break"  :)
14:33:43 <elodilles> :)
14:33:46 <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:34:24 <fungi> rosmaita: you could propose an alias for it in pbr, right now feature and deprecation have identical behavior, for example
14:34:34 <ttx> I'm not sure where the code that produces that patch is located
14:34:46 <rosmaita> that's ok, i was joking
14:34:49 <fungi> so there's precedent for having multiple terms for the same behavior
14:35:07 <rosmaita> we can do this as a one-off for glance, no need to revise it for everyone else
14:35:30 <rosmaita> our problem will go away during Z anyway, as the db migration code needs to be refactored
14:35:54 <ttx> I'm ok with trying it in master Z opening
14:36:05 <ttx> we might need to remember to amend the patch though
14:36:42 <rosmaita> so, to summarize: i can solve our problem for this current cycle by posting a patch with "Sem-Ver: api-break"
14:36:49 <rosmaita> that will bump the version for glance
14:37:15 <rosmaita> break the test, and then we update the constant
14:37:18 <rosmaita> thanks!
14:37:41 <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:53 <fungi> rosmaita: it's possible that the patch with "Sem-Ver: api-break" could be the patch which increments the migration serial
14:38:06 <fungi> (might even be necessary that they be the same patch)
14:40:20 <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:23 <rosmaita> fungi: i think the problem is that the test will fail so the patch incrementing the version can't land
14:40:34 <rosmaita> but we will think carefully
14:40:40 <rosmaita> elodilles: yes, that's right
14:40:44 <rosmaita> thanks, everyone!
14:41:01 <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:10 <fungi> but yeah, that doesn't need to be solved in the release meeting
14:42:03 <rosmaita> :0
14:42:05 <elodilles> maybe this is one thing (to update the reno-* patch generation) to the 'things to change' list?
14:43:03 <elodilles> i mean to add 'Sem-Ver: api-break' for rc deliverables (and leave 'feature' for cwi deliverables)
14:43:32 <elodilles> in case someone else needs it
14:44:06 <elodilles> do you see others with the same problem? is it worth to add this?
14:44:11 <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:39 <elodilles> fungi: hmm, that sounds logical
14:45:07 <fungi> not a show-stopper, but it could be inconvenient/confusing
14:45:36 <elodilles> so then it is OK how it is now... or at least, less painful, in case of a release model change
14:46:08 <elodilles> good, thanks
14:46:48 <elodilles> any other topic? anyone?
14:47:23 <ttx> nope
14:47:43 <elodilles> hmmm, sorry, i found one: https://review.opendev.org/q/topic:not-yet-released-yoga
14:48:09 <elodilles> so the release model changing patches can be mostly abandoned
14:48:18 <elodilles> i mean, except
14:48:21 <elodilles> ovn-octavia-provider
14:48:47 <elodilles> as neutron is OK with the change
14:49:04 <elodilles> any comment for this?
14:49:55 <hberaud> nope
14:49:58 <elodilles> (sorry, this was a task from last week and the deadline is today)
14:50:21 <elodilles> hberaud: ack, thanks :)
14:50:32 <ttx> works for me
14:50:36 <elodilles> ++
14:50:37 <hberaud> +1
14:51:15 <elodilles> if there is nothing else then let's close the meeting
14:51:22 <hberaud> nope
14:51:51 <diablo_rojo_phone> None from me
14:51:53 <elodilles> thanks everyone for joining!
14:52:03 <hberaud> Thanks elodilles
14:52:17 <elodilles> #endmeeting