17:00:00 #startmeeting releaseteam 17:00:02 Meeting started Thu Jan 28 17:00:00 2021 UTC and is due to finish in 60 minutes. The chair is hberaud. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:04 #link https://etherpad.opendev.org/p/wallaby-relmgt-tracking Agenda 17:00:05 The meeting name has been set to 'releaseteam' 17:00:08 Ping list: ttx armstrong elod 17:00:09 o/ 17:00:12 o/ 17:00:17 We're way down on line 300 now. 17:00:18 o/ 17:00:22 Will just wait a couple minutes for folks. 17:00:37 ok 17:04:20 ok let's go 17:04:24 #topic Review task completion 17:04:32 Review any remaining milestone-2 exceptions - Done 17:04:47 all the m-2 patches are now merged 17:05:04 Plan the next release cycle schedule - Done 17:05:13 I proposed a 25 week https://review.opendev.org/c/openstack/releases/+/772357 and a 24 week https://review.opendev.org/c/openstack/releases/+/772367 17:05:30 Feel free to leave comments or suggestions 17:06:19 Remove renderspec, rpm-packaging, pymod2pkg - Done ( https://review.opendev.org/c/openstack/releases/+/771963 ) 17:06:23 Thanks ttx 17:06:32 I think we can +W, ttx that's work for you? 17:07:21 yes 17:07:30 ok I proceed 17:08:19 done 17:08:41 drop EOL ocata branches - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020031.html thanks elod 17:08:49 np 17:09:17 I will use fungi 's pointers to propose some automation as soon as I get there 17:09:18 however AFAIK these branches aren't yet deleted, isn't? 17:09:32 no, not yet 17:09:33 elod: yes thanks 17:10:07 i still need to look at the list, if it's lengthy i'll need to devote an afternoon to handling them all 17:10:10 elod: I think fungi's proposal could be added to the `list_eol_branches` script, any opinion? 17:11:08 hberaud: that's an option, I haven't looked the other options yet 17:11:46 fungi: uhh, thanks for dealing with that. 17:12:26 fungi: one branch should be skipped for now: openstack/os-collect-config 17:12:27 elod: by taking a user account as a new parameter (the user should have the rights c.f fungi's comment) 17:12:36 it has still one patch open 17:12:43 the others are good to go 17:13:20 hberaud: sounds like a plan :) 17:13:41 fair enough thanks elod and fungi 17:13:51 \o/ 17:13:54 you bet 17:14:31 #topic Move to independent: do not copy history? 17:14:47 #link https://review.opendev.org/c/openstack/releases/+/772570 17:14:49 another of those grey process areas 17:15:07 Not sure if the case presented itself before 17:15:19 hmm good question 17:15:27 but my preference would be to not copy between named branches and _indepnedent 17:15:35 +1 17:15:50 Just wanted to make sure it made sense for everyone 17:16:06 if we agree, someone can drop a comment and we can move on 17:16:22 As far as I know yes 17:17:15 ok, let's do that, I'll -1 17:17:31 Mario updated the patch accordingly to our comments https://review.opendev.org/c/openstack/releases/+/772570/2..3 17:17:59 however we also need to remove the `release-model` entry 17:18:02 ok already fixed 17:18:08 next topic then! 17:18:25 #topic Unblock stale reviews 17:18:37 Switch to single-core approval if change propose by one of the cores 17:18:40 +1 17:18:51 I agree with that 17:18:55 yeah so.. patches propsoed by hberaud OR me tend to linger forever waiting for a second +2a 17:19:05 Any objection? 17:19:09 Merged openstack/releases master: RPM packaging deliverables no longer under relmgt https://review.opendev.org/c/openstack/releases/+/771963 17:19:27 I think it's good to pause a bit to give someone else a chance to comment, but we should feel free to self-approve 17:19:37 once it gets the other person's +2 17:19:52 or single-approve if we are the only one with a +2 in 17:20:02 yeah 17:20:26 OK I'll unblock a bunch of patches that are in this situation then 17:20:48 So, a patch proposed by a core with a self-approve of +2 needs only one +2 to be approved? 17:20:58 you are right it could be worth to wait a bit when we leave the +2 17:21:16 basically our authorship of the change counts as a second +2 before we do = 17:21:18 +a 17:21:30 for now for those currently open we have waited long enough 17:22:00 ok 17:23:06 Merged openstack/release-test master: Add doc/requirements https://review.opendev.org/c/openstack/release-test/+/769775 17:23:15 Anything else about this topic? 17:23:21 no 17:23:24 no 17:23:26 #topic Assign R-9 tasks one week in advance so that we can skip R-10 meeting 17:24:08 So first as $title said we will skip the next meeting 17:24:16 yeah, next week is basically the last meeting we can skip 17:24:28 before release tunnel 17:24:35 yes 17:24:43 So first topic 17:24:52 (and the only one) 17:24:56 Generate a list of intermediary-released service deliverables that have not done a release in this cycle yet 17:25:07 Any takers? 17:25:20 I am avialable to assist 17:25:23 I have limited availability on that week, so I'll leave it on the table 17:25:31 ok 17:25:50 thanks armstron_ 17:25:58 then I'll put our names 17:26:09 ok 17:27:26 I can propose to start to manage that on monday (around 2pm), that's work for you? 17:27:38 Yes, it works 17:27:44 2 pm UTC? 17:27:56 yes 17:28:00 sorry 17:28:13 I'll ping you on IRC 17:28:45 ok that is 9:00 AM EST 17:29:11 as someone who also lives on that slice of the globe, i agree with your timezone math 17:30:02 hahaha 17:30:19 armstron_: it's ok for you, I can move that one hour later if needed 17:30:25 ? 17:30:49 Sure, that is fine 17:30:54 ok 17:30:57 thanks 17:31:06 #topic Recent Release failures 17:31:58 just noticed a bunch 17:32:04 did anyone analyze them yet? 17:32:34 oh I my client email didn't let me know about the recent failure... 17:32:41 nope 17:32:45 ok looking 17:33:36 all seems to come from https://review.opendev.org/c/openstack/releases/+/772047 17:34:14 yeah 17:34:44 "python3 setup.py sdist bdist_wheel" returns: 17:34:50 Merged openstack/releases master: Add doc related to validation status (red, orange, green) https://review.opendev.org/c/openstack/releases/+/769171 17:34:51 ValueError: git history requires a target version of pbr.version.SemanticVersion(13.0.0), but target version is pbr.version.SemanticVersion(11.0.2) 17:34:53 error in setup command: Error parsing /home/zuul/src/opendev.org/openstack/os-collect-config/setup.cfg: ValueError: git history requires a target version of pbr.version.SemanticVersion(13.0.0), but target version is pbr.version.SemanticVersion(11.0.2) 17:35:03 weird 17:35:10 Merged openstack/releases master: [doc] updating when to change the release model https://review.opendev.org/c/openstack/releases/+/771579 17:35:24 same for /tripleo-ipsec 17:35:29 Merged openstack/releases master: Moving oslo projects to independent model https://review.opendev.org/c/openstack/releases/+/764624 17:35:42 Merged openstack/releases master: etcd3gw - adopting the independent release model https://review.opendev.org/c/openstack/releases/+/771383 17:36:02 Merged openstack/releases master: Octavia: EOL Stein branch https://review.opendev.org/c/openstack/releases/+/772847 17:36:08 the paunch one was more of a release note fail (no release notes to build, can probably be ignored) 17:36:37 ussuri doesn't exist => https://opendev.org/openstack/os-collect-config 17:36:43 so for the first two we do have a tag up but no release published 17:37:23 https://opendev.org/openstack/os-collect-config/branches/ 17:37:33 hmmm 17:37:55 and the changes was on deliverables/ussuri/os-collect-config.yaml 17:37:58 So yeah they are missing stable/ussuri and still makign a release 17:38:12 Do you think it could be the root cause? 17:39:00 I don't even... 17:39:02 that would trigger unexpected side effect on pbr 17:39:18 as pbr retrieve info by using git 17:39:22 how were those changes pushed to ussuri in absence of a stable/ussuri branch? 17:39:43 how could they release 11.0.0 and 11.0.1 without stable/ussuri? :-o 17:39:56 elod: during teh cycle maybe 17:40:12 used SHA is on master 17:40:17 i see 17:40:22 https://opendev.org/openstack/os-collect-config/commit/cc519a7d4844ef7a48ab69abf1d2dd0f90e7bafd 17:40:42 yeah, so the issue here is that this is a release on an old branch, but where stable/ussuri was never cut 17:40:54 Marios Andreou proposed openstack/releases master: Move os-apply|collect|refresh-config projects to independent https://review.opendev.org/c/openstack/releases/+/772570 17:40:58 I wonder why our validation doesn't failed 17:41:39 Also how did that escape our stable branching at release requirements 17:42:06 good question 17:42:08 that tag is now a bit in limbo 17:42:34 I suspect it escaped our watch because it's release-trailing 17:42:46 side question, do we want to stop => https://review.opendev.org/c/openstack/requirements/+/772911 17:42:49 ? 17:43:11 sorry wrong link 17:43:29 V 17:43:35 https://review.opendev.org/c/openstack/requirements/+/772862 17:45:09 it does have stable/victoria 17:45:46 yes I think that the trailing model could explain that situation 17:45:46 re 772862 13 looks good to me 17:45:55 Yes my bad 17:46:08 ok, we probably won;t fix it tonight 17:46:28 Maybe open a thread so that we start discussing those two 17:46:28 to many os-collect-config patches at the same time 17:46:28 Yes 17:46:39 assuming triopeo-ipsec is in the same situation 17:47:07 Will do it by monday 17:47:30 I wonder if we should not remove those tags as they may bite us in the future as we try to fix this 17:47:52 This is what I was thinking 17:48:02 Do we faced similar situation in the past? 17:48:24 no, process is supposedly there to protect us from this situation 17:48:46 Ok then I prefer to remove those tags 17:49:42 yes, at first glance I would remove the tag, branch stable/ussuri at latest ussuri release, then do a new release at branch point X.Y.Z+2 17:49:44 even if it means redoing things properly before moving some of these to independent 17:50:22 starting by reverting those two 17:50:34 +1 17:50:54 I suppose we need to ask to fungi? ^ 17:51:01 that will not completely rewrite history, which is why i'd advise jumping to Z+2 17:51:25 I see 17:51:27 I expect he will chime in on the thread 17:51:36 yes 17:52:09 Ok I'll start the thread with that 17:52:15 1) drop the tags 17:52:18 yeah, i can follow up on th eml 17:52:21 the ml 17:52:30 2) do a new release Z+2 17:52:39 thanks 17:52:47 hmm 0)revert those two deliverable file changes 17:52:55 by "remove the tag" i assume we don't mean delete actual git tags from the repos, that doesn't really go well 17:53:21 but i'm only half following the problem at this point 17:53:22 fungi: I fear that the presence of the tag in the repo will break future releases validation 17:53:33 yes, let;s punt that to the thread 17:53:37 Ah yes exact 17:53:45 ok move on 17:54:09 #topic Open Floor 17:54:15 Anything else? 17:54:24 noep 17:54:58 nothing from me either 17:55:13 re: those failures alternatively we could let the move to _independent happen and punt until a new release is requested see if it fails or not :) 17:55:54 but I assume they did those ussuri releases for a reason 17:56:15 I'll ping Mario to ask their opinion 17:56:30 maybe describe the problem on a thread first 17:56:34 yes 17:56:38 so that everyone has the same info 17:56:43 yes 17:58:52 Well I update our pad 17:58:59 OK, thanks everyone. Almost there! 17:59:11 nothing from me 17:59:11 #endmeeting