Friday, 2022-08-05

*** marios is now known as marios|ruck05:44
*** amoralej|off is now known as amoralej06:13
*** dviroel|out is now known as dviroel11:14
*** amoralej is now known as amoralej|lunch13:26
elodillesreminder: weekly meeting will start in less than 15 mins13:46
*** amoralej|lunch is now known as amoralej14:00
elodilles#startmeeting releaseteam14:00
opendevmeetMeeting started Fri Aug  5 14:00:51 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'releaseteam'14:00
elodillesPing list: armstrong ttx hberaud diablo_rojo_phone14:01
hberaudo/14:01
armstrongo/14:01
elodilles#link https://etherpad.opendev.org/p/zed-relmgt-tracking14:01
ttxo/14:01
diablo_rojo_phoneHello! 14:01
elodilleso/14:01
elodilleswe are at line 253!14:01
elodilleslet's start quickly with the topics as we have quite many topics in our agenda!14:02
elodilles#topic Review task completion14:02
elodilles1st task was: 'Generate a list of intermediary-released service deliverables that have not done a release in this cycle yet and propose release model change for them.'14:02
elodillessince the generated list is mostly the same as usual (and we usually abandon the release model change patches for them) i've sent a mail instead:14:03
elodilleshttps://lists.openstack.org/pipermail/openstack-discuss/2022-August/029798.html14:03
elodillesas a result, vitrage deliverables were released14:03
armstrongok14:04
elodillesironic , OpenStackSDK and swift are still pending14:04
elodillesanything to add here?14:05
ttxnope14:05
armstrongwill you force the release on these three projects?14:05
elodillesgood question. maybe not force, but i could ping them as a gentle reminder on IRC :)14:06
armstrongok14:06
elodilles#action elod to ping ironic OpenStackSDK and swift to prepare releases for the missing deliverables14:07
elodillesthanks armstrong for the question :)14:07
elodillesokay, next topic then14:07
armstrongnp14:07
elodillesi mean, next task...14:08
elodilles'Propose convenience releases for Wallaby to ease the transition of Wallaby to Extended Maintenance and avoid rush and broken releases when the transition deadline is coming.'14:08
elodillesactually, i've proposed ~1 month ago: https://review.opendev.org/q/topic:wallaby-stable14:08
elodillesand ~half of them have merged already14:09
elodillesthose patches which won't get +1's from PTL/release liaisons will be abandoned soon14:10
elodillesand that was the last task14:11
elodilles#topic Assign R-8 tasks14:11
elodillesactually, only two small tasks are there, so i added my name to them14:11
elodillesif there's no objection :)14:12
elodilles(in case there is, just add your name to the task ;))14:12
elodilleslet's move on to the next topic!14:13
elodilles#topic PTG October 2022 Team Signup (Columbus, Ohio)14:13
* elodilles still doesn't have the final approval for the travel from his company14:13
armstrongI will add my name :)14:14
elodilleshopefully i will get soon14:14
elodillesbut it's holiday season14:14
diablo_rojoI shall be there :)14:14
elodilles:)14:14
elodillesi think I can still signup the team for the PTG14:15
diablo_rojoYou can :) \14:15
diablo_rojoYou have till the 12th14:15
armstrong@diablo_rojo  are the ticket free?14:15
hberaudsame thing for me, I don't yet know about my company approval14:15
diablo_rojoarmstrong: since its an in person event, they are not. 14:16
armstrong:( 14:16
ttxi think signing up the team is pretty harmless at this point !14:17
ttxI don;t think we'll do that many hours but always good to be on the agenda14:17
elodillesttx: i agree14:18
elodilles#agreed elod will signup the release team for PTG14:18
elodillesand let's hope everyone will be able to travel there14:18
elodillesanything else to discuss about the Team Signup?14:19
ttxif not it should not be too difficult to plug a single remote attendee in14:19
diablo_rojoNothing from me. 14:19
ttxit's when large groups are involved that it can quickly turn into a mess14:20
elodillesttx: yes, we probably could manage it easily14:20
elodillesokay, next topic then14:21
elodilles#topic Antelope release date pick14:21
elodilleshttps://review.opendev.org/c/openstack/releases/+/85075314:21
elodillesthis is the proposed schedule ^^^14:21
elodilles(or this one for better readability: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_699/850753/5/check/openstack-tox-docs/699fc2d/docs/antelope/schedule.html )14:22
elodillesit's according to Foundation's response for the 1st proposal14:22
ttxYeah my main issue with it is that it forces the next PTG to be the release week14:22
ttxwhich is why I suggested to move it up a week.... but we could also just say it's ok14:23
ttxMaybe we could build two options and ask around about the preference... possibly let the TC decide14:24
elodillesaccording your other suggestion to release at March 22, then the PTG would be just next week, before Easter i guess14:24
elodillesisn't that also a risky timing?14:25
elodillesanyway, i can propose that schedule as well as you suggest14:25
ttxeaster and Passover week is the week after14:26
ttxMar 20-26: none14:26
ttxMar 27-Apr 2: none14:26
ttxApr 3-9: passover starts April 5, easter starts April 7 14:26
elodilleshmmm, ok, maybe that could work14:27
ttxI think it works, it's just less ideal in terms of duration and where milestones fall14:27
ttxquestion being, what do we care about the most14:28
elodilles#action elod to propose another schedule plan (w/ March 22 release date) and let folks / Foundation / TC decide14:28
ttxRelease week can get busy as we do promotion that involve PTLs etc14:28
elodillesttx: ack14:28
elodillesttx: is this acceptable? ^^^14:28
ttxso making that two difefrent weeks avoids too much collision14:28
ttxelodilles: yes. I'd let the TC decide really, once people voice their preference on the reviews14:29
elodillesttx: ack, thanks for the ideas14:29
elodillesthen let's move on to next topic14:29
elodilles#topic Hacking release so late in the cycle? https://review.opendev.org/c/openstack/releases/+/85127314:30
elodillesafaik there were some issues in the past when hacking was released and CI jobs started to break14:31
ttxyep, hacking releases we usually push during meilstone-114:31
elodillesthat's why it is best to release early in the cycle14:31
ttxso that if they trigger some work it does not conflict with any planned release work14:32
elodilleswe are just between zed-2 and zed-314:32
armstrongso the entire code base is moving to 3.10?14:32
elodillesarmstrong: i don't think so14:32
elodillesthe patch just drops py36 & py37 support14:33
elodilleswhat every project should have done already14:33
armstrongok thx14:34
elodillesand it does other things like 'support flake8 4.x' etc14:35
elodillesanyway, the question is, whether we are really late (between zed-2 and zed-3)14:36
ttxMy vote would be on postponing14:36
ttxbut it's not a strong opinion14:36
hberaudI agree with you to postpone it14:36
fungiyes, that seems like it could be generally disruptive so late in the cycle14:36
elodillesi agree too,14:37
ttxit's more a question of habit. If there is no strong reason to push it late, we should defer it14:37
fungithis may provide incentive for the qa team to plan changes for static analysis tools and similar linters so they can merge soon after the coordinated release14:37
elodillesjust really hope that there won't be such case when someone comes with the idea to urge us to release anyway, around release time :)14:38
elodillesbut i guess that possibility is weak (fingers crossed)14:38
elodillesanyway, we are on consensus as i see14:39
elodillesto postpone it to release it early in Antelope cycle14:40
elodilles#agreed to postpone Hacking 5.0.0 release to eearly time in Antelope cycle14:42
elodillesis this OK ^^^?14:42
ttx++14:43
elodillesack, then i'll comment on the release patch in behalf of the team14:43
elodillesnext topic then14:43
elodilles#topic Review countdown email contents14:43
elodilles#link https://etherpad.opendev.org/p/relmgmt-weekly-emails14:43
elodillesplease review ^^^14:43
elodillesnote that i did a bit bigger change in the mail than the usual,14:44
elodillesdue to the changes in the 1st task14:44
elodilles(the crossed out sections won't be part of the mail)14:44
elodilles(just showing the original content to see what will be left out)14:45
armstrong^^^ LGTM!14:46
elodillesarmstrong: ++14:47
armstrongthe  the "*swift "is this the project level? or  a *swift- team within Swift? 14:48
elodillesthe 'swift' deliverable from Swift team :)14:49
armstrongok thx for the clarification 14:49
ttxlgtm14:50
hberaudLGTM14:50
elodillesthanks!14:50
elodilles#topic Open Discussion14:50
elodillesanyone, anything to discuss?14:51
hberaudJust a friendly reminder about my PTO14:51
hberaudI'll be afk during the next 3 weeks14:51
elodilleshberaud: acknowledged, have a nice time off! :)14:51
hberaudthat's all for me14:51
hberaudthanks14:51
ttxhave a good time off!14:52
hberaudthanks14:52
elodillesokay, we had the long silence :)14:54
elodillesso let's close the meeting!14:54
elodillesthanks everyone for participating! o/14:55
elodilles#endmeeting14:55
opendevmeetMeeting ended Fri Aug  5 14:55:19 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:55
opendevmeetMinutes:        https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-08-05-14.00.html14:55
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-08-05-14.00.txt14:55
opendevmeetLog:            https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-08-05-14.00.log.html14:55
armstrongthanks14:55
elodillesarmstrong: ++14:55
hberaudelodilles: thanks14:55
elodilleshberaud: ++14:55
fungioh, i meant to mention, but my investigation into the pbr release validation error has stalled. i don't know how to reproduce it outside the rather convoluted validation script15:03
fungiwhen i try to run what commands it looks to me like that script is running, it just works15:04
elodillesfungi: i had the same result so far :/15:10
elodillesi don't see how the 'build' package gets lost during the job (as it is installed, as clearly visible with in the tox's pip freeze output)15:12
fungiclarkb: not urgent, but if you end up with a free moment at some point, a fresh pair of eyes on https://review.opendev.org/851972 might help. i expect i'm overlooking something trivial which explains that failure15:14
fungisomething has obviously changed between the last pbr tag 3 months ago and now15:15
fungimy money's on something related to build isolation and/or recent setuptools behavior changes15:15
fungibut the problem seems to be specific to pbr15:17
fungi(to pbr building itself i mean, other pbr-using projects aren't hitting this)15:17
clarkbseems like that validation script needs to log what failed15:18
clarkbthe rc value isn't sufficient informatoin15:18
clarkb`/home/zuul/src/opendev.org/openstack/releases/.tox/validate/tmp/releases-49kdh7bq/openstack/pbr/.tox/venv/bin/python3: No module named build` maybe?15:19
clarkbdo you need to list build as a build dep somewhere?15:20
fungiyeah, i've been assuming that's the reason for the nonzero return15:21
fungibut build does seem to exist in the venv15:21
clarkbnote its a nested venv15:21
fungithe logs show it being installed15:21
funginested in what sense?15:21
clarkbis build getting installed to /home/zuul/src/opendev.org/openstack/releases/.tox/validate but not /home/zuul/src/opendev.org/openstack/releases/.tox/validate/tmp/releases-49kdh7bq/openstack/pbr/.tox/venv ?15:21
clarkbthere are two tox envs there ^15:22
fungiahh, nested in the filesystem sense15:22
fungiis that nested venv something that would be unique to pbr itself, because releases of other stuff aren't hitting this15:22
clarkbI don't know. I'm not sure I've ever looked at this validaton script before15:23
clarkbI think the validation script is running out of a tox env and for the releases it is validating it runs tox -evenv to operate on the repos?15:24
clarkbmaybe pbr's venv tox target is not compatible with whatever interface this script assumes15:24
fungii think it's using the releases repo's tox.ini15:25
fungiat least from what i was able to trace15:25
clarkbfor the first tox env yes. But for the second? that .tox dir for the second lives under openstack/pbr15:25
clarkbhttps://zuul.opendev.org/t/openstack/build/58c0b20854574742b390453c40d18447/log/job-output.txt#1161 it does install build to the validate top level tox env15:26
fungioh, yes okay the function in releases calls `tox -e venv --notest` in pbr to create that15:26
clarkbBut i haven't seen anything doing that in the pbr venv env yet15:26
*** dviroel is now known as dviroel|lunch15:26
fungii wonder if that extra step is unnecessary15:27
clarkbthe pbr venv env installs pbr's test-requirements.txt15:27
fungibuild doesn't need to be run from a pbr tox venv, it just needs to be run pointed at the pbr source tree15:27
clarkbwheel is in that list but not build15:27
clarkbI suspect the validte script was updated to use build but not all of the repos that it validates install it properly15:27
fungiwell, repos shouldn't need to install build themselves. it's like twine in that regard, it doesn't need the project or its deps installed15:29
clarkbI agree, but my hunch is that is the interface currently designed15:29
fungibuild does the installing on its own regardless15:29
fungiright, i'm saying i think i can correct this by changing the validate function to call the copy of build it installed15:29
clarkbya that should work15:30
fungiclarkb: huh... the code i'm about to rip out is actually pbr-specific: https://opendev.org/openstack/releases/src/branch/master/openstack_releases/pythonutils.py#L77-L8715:33
fungii hadn't noticed that until this moment15:33
fungilooks like that was added by https://review.opendev.org/590476 almost exactly 4 years ago15:35
clarkbweird seems useful for all repos15:36
fungiwell, i think the idea is that you shouldn't need to directly install anything in order to build the project's sdist and wheel15:37
opendevreviewJeremy Stanley proposed openstack/releases master: release pbr  https://review.opendev.org/c/openstack/releases/+/85197215:39
opendevreviewJeremy Stanley proposed openstack/releases master: Remove PBR-specific validation code  https://review.opendev.org/c/openstack/releases/+/85227715:39
fungihopefully that'll pass15:39
clarkbI mean validating an sdist builds is valuable15:40
fungioh, right. this still does15:40
fungithe validation is done for all projects, but there was special handling in the build_sdist() function for pbr which i ripped out15:41
clarkbits the nested tox that is pbr specific. gotcha15:41
fungiit's the only one using that nested venv instead of building from the validation venv15:41
*** marios|ruck is now known as marios|out15:52
elodillesand it works \o/15:55
elodillesthanks for figuring it out15:55
elodillesi was lost in the logs and haven't thought about we have a special handling of pbr :S15:56
elodillesespecially as it worked locally :-o15:57
fungiyeah, until clarkb got me looking closer at the reason for the second venv, it hadn't dawned on me that the entire codepath there was unique to pbr builds16:03
fungiwhich of course explains precisely why only pbr was hitting it ;)16:04
elodillesyepp :)16:06
fungielodilles: per your comment on 851972, keep in mind that you could set the ptl approved label to carry over on trivial rebases if you like16:09
*** amoralej is now known as amoralej|off16:10
fungiso if the change didn't have to be altered to resolve some merge conflict, it would just assume the vote for that continued to be valid16:10
fungioh, in fact i think it already is set that way, it's the zuul configuration which is removing it16:11
fungiprobably the job could be made smarter to accommodate that case, but maybe that's overengineering it16:11
*** dviroel|lunch is now known as dviroel16:30
elodillessad update about the PTG: 19:35
elodilleshttps://lists.openstack.org/pipermail/openstack-discuss/2022-August/029879.html19:36
elodilles:'(19:36
*** dviroel is now known as dviroel|brb19:40
*** dviroel|brb is now known as dviroel20:56
*** dviroel is now known as dviroel|out21:12

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!