14:00:52 #startmeeting releaseteam 14:00:52 Meeting started Fri Feb 25 14:00:52 2022 UTC and is due to finish in 60 minutes. The chair is elodilles. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:52 The meeting name has been set to 'releaseteam' 14:00:57 o/ 14:01:05 Ping list: hberaud ttx armstrong damani 14:01:09 o/ 14:01:18 #link https://etherpad.opendev.org/p/yoga-relmgt-tracking 14:01:32 o/ 14:01:43 we are at line 288 14:01:51 hello everyone \o/ 14:03:10 elodilles: sorry for last week I missed to mark me as in PTO in our agenda 14:03:38 hberaud: no problem :) 14:04:17 let's start as we have a long list for tasks :) 14:04:38 #topic Review task completion 14:04:44 1st task: 14:04:54 "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. (hberaud|damani)" 14:05:18 looks like it's under discussion finally 14:05:43 so yes the patch have been proposed 14:05:55 https://review.opendev.org/c/openstack/governance/+/830454 14:06:20 nice, then we are on track i guess 14:06:23 i have a feeling continued delays for rhel 9 and the new annual upgrades plan will impact the outcome there 14:06:40 ack 14:06:44 :S 14:07:39 do we want to add some follow up task for this, or is it enough that we have the patch? 14:08:07 can't hurt 14:08:19 I think the patch is enough 14:08:54 but we are near from the final so I'd suggest to simply keep an eye on this point 14:09:05 ok, thanks, i'll try to keep an eye on the patch then :) 14:09:06 to ensure that everything is aligned 14:09:14 agreed :) 14:09:23 next task: 14:09:32 "Process any remaining library freeze exception (elod/all)" 14:09:44 actually there were no exceptions 14:09:47 (so far?) 14:10:05 the openstacksdk patch is merged/closed? 14:10:15 the one with the comment 14:10:46 * elodilles searching for the patch 14:10:46 (that said that openstacksdk won't release much things within Y) 14:11:09 well, that is open. they have a release already, 14:11:29 but after that a significant amount of patches has landed 14:11:32 so then I think we can close it, isn't? 14:11:39 ok 14:12:04 you mean this one: 14:12:05 https://review.opendev.org/c/openstack/releases/+/829081 14:12:12 * hberaud looks 14:12:19 no answer from Artem 14:12:22 yes 14:12:38 to me it was a bit strange to have that amount of patches unreleased 14:12:59 yes 14:13:39 (especially because as far as i know openstacksdk does its development on feature branches, so why did they merge the feature branch then if they don't want to release it?) 14:13:54 no idea 14:14:20 what's their irc channel? 14:14:27 #openstack-? 14:14:46 #openstack-sdks 14:14:51 SDKs 14:14:54 Yep 14:14:58 openstack-sdks 14:15:00 ues 14:15:42 Artem is not connected 14:15:44 They don't normally do feature braches. This was a particularly complicated and large and far teaching piece of work 14:15:51 gtema? 14:15:54 yes 14:16:29 Ah yep. 14:16:56 He's in Germany so he should still be online but perhaps he's on vacation or something 14:17:20 ok 14:17:27 diablo_rojo_phone: thanks for the info :-o 14:17:34 elodilles and I leave a comment on their channel 14:17:37 hberaud + me just pinged them on irc 14:17:38 :D 14:17:40 :) 14:17:48 let's wait for their feedback 14:17:56 yepp 14:18:20 thanks hberaud for reminding me to this patch! 14:18:22 without response next week I'd suggest to send an email 14:18:33 np 14:18:45 hberaud: ack, good idea! 14:18:59 elodilles: gtema just replied 14:19:09 (on their channel) 14:21:05 #openstack-sdks 14:21:16 er, wrong buffer recall, sorry! 14:21:39 (i also hate that when that happen: wrong buffer ;)) 14:22:04 so Artem still holds the original comment ("no changes can be release at the moment. Yoga will will stay at current version") 14:22:30 i've just abandoned the patch 14:22:40 WFM 14:22:46 so the next task: 14:23:07 "Propose autoreleases (process_auto_releases) for cycle-with-intermediary client libraries which had commits that have not been included in a release." 14:23:25 the patches: https://review.opendev.org/q/topic:yoga-milestone-3 14:23:54 some remained without review from PTL/release liaison 14:24:10 I don't think we have to wait for those patches 14:24:18 i'll force-approve those after the meeting 14:24:28 ack 14:24:30 WFM 14:24:34 ++ 14:25:13 so i think we are good with that task 14:25:29 "Evaluate any libraries that did not have any change merged over the cycle to see if it is time to transition them to the independent release model." 14:26:09 i've run the script that showed some of the not-yet-morged patches from the above yoga-milestone-3 group 14:26:20 and two other deliverables: 14:26:31 keystoneauth and kuryr 14:26:47 we missed these two last week :S 14:26:59 so I'll propose patches for them after the meeting 14:27:00 I don't think we want to move keyestone to the independent model 14:27:56 hmmm, sorry, i was wrong, 14:28:09 these have not been released actually, 14:28:12 Concerning kuryr, why not, however I think this is a collegial decision 14:28:15 but they have some patches 14:28:18 ok 14:28:57 just wanted to mention that we forgot to release them 14:29:45 Oh okay 14:29:57 i caught them during running the scripts for the task 14:30:21 concerning those from the M3 patches, those deliverables are strongly coupled with services so I'd suggest to keep them aligned under the same release model 14:31:18 its not too late to release them 14:31:30 (keystone and kuryr) 14:31:36 hberaud: ack 14:32:30 on the other hand i think i need further look at releases, because there were some without real/significant commits 14:32:51 so i'm planning to do some follow up here 14:33:02 ok 14:33:16 and maybe we can discuss them next week's meeting 14:33:47 ok 14:33:50 #action elod to evaluate released libraries without significant content 14:34:01 added a reminder to myself ^^^ :) 14:34:05 anyway 14:34:08 next task 14:34:46 "List cycle-with-intermediary deliverables that have not been released yet" 14:35:06 this was done by armstrong , see mail: http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027379.html 14:35:12 thanks armstrong ! 14:35:36 NP 14:35:46 and if I'm not mistaken all but one deliverables got release patches 14:36:07 patrole is still missing 14:36:44 i'll ping QA team and we will see 14:37:33 next task 14:37:41 "On Friday, remind the requirements team to freeze changes to openstack/requirements by applying -2 to all open patches." 14:37:50 prometheanfire: ^^^ o:) 14:38:16 hberaud: do we have any other TODO with this? o:) 14:38:43 to be vigilant :) 14:39:03 i did suggest in #openstack-sdks that they consider switching to the independent release model since they don't seem to be releasing and freezing along with other libraries 14:39:05 as always ;) 14:39:31 fungi: oh, good idea :-o 14:39:37 usually during the two last series I was checking daily the requirements patches 14:39:40 fungi: thanks for proposing that 14:39:54 indeed good idea 14:40:17 hberaud: ack 14:40:26 so maybe I need to reconcider my POV concerning keystone 14:41:18 hberaud: do you see something there with keystone? :-o 14:41:47 yes... inactivity 14:41:53 :S 14:42:19 and so maybe a good candidate for the independent model 14:42:42 then I'll propose a release model changing patch there and we can discuss it there 14:42:47 however keystone is strongly coupled with series IIUC 14:42:58 ok 14:43:08 that's a good start 14:43:14 thanks for noting! 14:43:19 last task 14:43:31 it's possible we'll see this more and more if service projects approach a "feature complete" state and don't really have something to add in a particular cycle 14:43:32 Sorry, that was our last task :) 14:43:43 yes 14:43:51 fungi: yepp, i agree 14:44:25 hopefully we can get to a point where low levels of activity in a deliverable imply that it's stable, does what it's meant to, and has few remaining bugs 14:44:29 fungi: on the other hand we might need some discussion around that (maybe on PTG?) because not all teams are fond of 'independent' release model changes 14:44:37 as far as I remember... 14:45:08 fungi: ++ 14:45:49 i'll add this topic to our 'things to change' maybe after the meeting 14:45:57 we've gotten so used to constant churn in projects, that we can forget that's only one phase of a software's development 14:46:21 yeah, probably that's true 14:46:33 It's true. There comes a time where there's actual stability. 14:46:50 More or less feature complete and sans bugs 14:47:11 diablo_rojo_phone: ++ 14:47:19 anyway, let's move on as we are running out of time :) 14:47:28 #topic Assign R-4 week tasks 14:48:00 please add your names to the tasks if you'll be around and can take them 14:48:32 I'm on PTO all the next week so I'll be totally disconnected and without laptop 14:48:39 hberaud: thanks, noted! 14:49:14 so... I won't volunteer 14:49:17 :) 14:49:33 understandably :) 14:50:13 all taken, next topic 14:50:16 Lol 14:50:20 however next week is a quiet week 14:50:46 yeah, after feature freeze it should be ;) 14:50:47 #topic Review countdown email contents 14:51:09 #link https://etherpad.opendev.org/p/relmgmt-weekly-emails 14:51:42 i've filled the template, please review ^^^ 14:52:56 LGTM 14:53:10 ack, thanks! 14:53:18 LGTM too 14:53:23 armstrong: ++ 14:53:28 elodilles: guess it's that time again? 14:53:43 prometheanfire: yes, it is, indeed :) 14:54:34 prometheanfire: let me know if I can help with something 14:56:01 i've added another topic to the agenda, it's more like some review heads-up: 14:56:19 #topic "Release identification and release naming" proposal: https://review.opendev.org/c/openstack/governance/+/829563 14:56:25 elodilles: https://review.opendev.org/829599 is gonna be the main thing to deal with 14:57:49 prometheanfire: ack, added myself to the patch so that i won't forget it :) 14:58:23 it would probably be good to ask for clarification on 829563 as to what expectations they have for the release managers 14:59:08 regarding the identification / name proposal: I've seen that Thierry and Sean already reviewed it, thanks! so feel free to review it. I'm planneng to read it through thoroughly by myself as well 14:59:10 because as it's written now, it just boils down to "we can also refer to the release by a year.number" (which doesn't imply any actual alterations to tooling or processes) 15:00:02 i expect at a minimum the implication is that the releases site would additionally show the "release number" 15:00:11 fungi: name + number, if i'm not mistaken, but have to read it carefully 15:00:12 but that's reading between the lines 15:00:23 yes, name and number, hence my use of "also" 15:00:36 fungi: ack 15:00:50 so, please review if you have time :) 15:00:59 it doesn't actually say that the release team/site needs to stop using the cycle name as the primary indicator though 15:01:05 last quick topic then 15:01:15 #topic Open Discussion 15:01:25 I see that rosmaita has added one 15:01:34 "any resolution to https://review.opendev.org/c/openstack/releases/+/829590/3/deliverables/wallaby/os-brick.yaml#30 ?" 15:02:11 actually I had a comment on it that the patch is a bit like exception from stable-policy perspective 15:02:26 we are open to suggestions about better docs to accompany the backport 15:02:27 i hoped that smcginnis would comment on it o:) 15:02:39 (assuming that you don't outright decide that we need to revert it) 15:02:40 though i know he is just very rarely around 15:03:36 i don't know that there's a big rush, though things will only get busier over the next few weeks 15:03:40 rosmaita: i just wanted to call your attention that the patch is not fitting for stable policy (but maybe i am wrong) 15:04:04 rosmaita: sure, the sooner we get reviews, the better 15:04:26 elodilles: yes, i understand your point, but it's kind of a bad bug for people who hit it 15:05:07 what's the impact to people who aren't hitting that bug upgrading to the new point release without paying close attention to the release notes? 15:05:08 rosmaita: ack, I'm open to accept it, especially if the team agrees 15:06:10 fungi: i am not 100% sure ... i thought it was not a big deal, but in discussion the other day, it may be problematic 15:06:19 guess i need to get a definite answer 15:07:27 i'd still like to get sean's opinion; in the meantime, i will follow up with the cinder team about operator impact 15:07:29 yeah, it seems like a question of whether the impact of the bug is overall worse than the impact of operators assuming stable point releases don't require configuration changes 15:08:05 rosmaita: thanks, that sounds like a good way forward! 15:08:08 i'll take an action item to get some details to leave on the patch 15:08:15 thanks! 15:08:19 rosmaita: thanks too! 15:08:27 we are overtime 15:08:34 so if no objection 15:08:43 then let's close the meeting now 15:08:48 np 15:08:51 3 15:08:51 2 15:08:53 1 15:08:53 Fine by me 15:08:57 #endmeeting