*** marios is now known as marios|ruck | 05:44 | |
*** amoralej|off is now known as amoralej | 06:13 | |
*** dviroel|out is now known as dviroel | 11:14 | |
*** amoralej is now known as amoralej|lunch | 13:26 | |
elodilles | reminder: weekly meeting will start in less than 15 mins | 13:46 |
---|---|---|
*** amoralej|lunch is now known as amoralej | 14:00 | |
elodilles | #startmeeting releaseteam | 14:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
opendevmeet | The meeting name has been set to 'releaseteam' | 14:00 |
elodilles | Ping list: armstrong ttx hberaud diablo_rojo_phone | 14:01 |
hberaud | o/ | 14:01 |
armstrong | o/ | 14:01 |
elodilles | #link https://etherpad.opendev.org/p/zed-relmgt-tracking | 14:01 |
ttx | o/ | 14:01 |
diablo_rojo_phone | Hello! | 14:01 |
elodilles | o/ | 14:01 |
elodilles | we are at line 253! | 14:01 |
elodilles | let's start quickly with the topics as we have quite many topics in our agenda! | 14:02 |
elodilles | #topic Review task completion | 14:02 |
elodilles | 1st 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 |
elodilles | since 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 |
elodilles | https://lists.openstack.org/pipermail/openstack-discuss/2022-August/029798.html | 14:03 |
elodilles | as a result, vitrage deliverables were released | 14:03 |
armstrong | ok | 14:04 |
elodilles | ironic , OpenStackSDK and swift are still pending | 14:04 |
elodilles | anything to add here? | 14:05 |
ttx | nope | 14:05 |
armstrong | will you force the release on these three projects? | 14:05 |
elodilles | good question. maybe not force, but i could ping them as a gentle reminder on IRC :) | 14:06 |
armstrong | ok | 14:06 |
elodilles | #action elod to ping ironic OpenStackSDK and swift to prepare releases for the missing deliverables | 14:07 |
elodilles | thanks armstrong for the question :) | 14:07 |
elodilles | okay, next topic then | 14:07 |
armstrong | np | 14:07 |
elodilles | i 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 |
elodilles | actually, i've proposed ~1 month ago: https://review.opendev.org/q/topic:wallaby-stable | 14:08 |
elodilles | and ~half of them have merged already | 14:09 |
elodilles | those patches which won't get +1's from PTL/release liaisons will be abandoned soon | 14:10 |
elodilles | and that was the last task | 14:11 |
elodilles | #topic Assign R-8 tasks | 14:11 |
elodilles | actually, only two small tasks are there, so i added my name to them | 14:11 |
elodilles | if there's no objection :) | 14:12 |
elodilles | (in case there is, just add your name to the task ;)) | 14:12 |
elodilles | let'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 company | 14:13 | |
armstrong | I will add my name :) | 14:14 |
elodilles | hopefully i will get soon | 14:14 |
elodilles | but it's holiday season | 14:14 |
diablo_rojo | I shall be there :) | 14:14 |
elodilles | :) | 14:14 |
elodilles | i think I can still signup the team for the PTG | 14:15 |
diablo_rojo | You can :) \ | 14:15 |
diablo_rojo | You have till the 12th | 14:15 |
armstrong | @diablo_rojo are the ticket free? | 14:15 |
hberaud | same thing for me, I don't yet know about my company approval | 14:15 |
diablo_rojo | armstrong: since its an in person event, they are not. | 14:16 |
armstrong | :( | 14:16 |
ttx | i think signing up the team is pretty harmless at this point ! | 14:17 |
ttx | I don;t think we'll do that many hours but always good to be on the agenda | 14:17 |
elodilles | ttx: i agree | 14:18 |
elodilles | #agreed elod will signup the release team for PTG | 14:18 |
elodilles | and let's hope everyone will be able to travel there | 14:18 |
elodilles | anything else to discuss about the Team Signup? | 14:19 |
ttx | if not it should not be too difficult to plug a single remote attendee in | 14:19 |
diablo_rojo | Nothing from me. | 14:19 |
ttx | it's when large groups are involved that it can quickly turn into a mess | 14:20 |
elodilles | ttx: yes, we probably could manage it easily | 14:20 |
elodilles | okay, next topic then | 14:21 |
elodilles | #topic Antelope release date pick | 14:21 |
elodilles | https://review.opendev.org/c/openstack/releases/+/850753 | 14:21 |
elodilles | this 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 |
elodilles | it's according to Foundation's response for the 1st proposal | 14:22 |
ttx | Yeah my main issue with it is that it forces the next PTG to be the release week | 14:22 |
ttx | which is why I suggested to move it up a week.... but we could also just say it's ok | 14:23 |
ttx | Maybe we could build two options and ask around about the preference... possibly let the TC decide | 14:24 |
elodilles | according your other suggestion to release at March 22, then the PTG would be just next week, before Easter i guess | 14:24 |
elodilles | isn't that also a risky timing? | 14:25 |
elodilles | anyway, i can propose that schedule as well as you suggest | 14:25 |
ttx | easter and Passover week is the week after | 14:26 |
ttx | Mar 20-26: none | 14:26 |
ttx | Mar 27-Apr 2: none | 14:26 |
ttx | Apr 3-9: passover starts April 5, easter starts April 7 | 14:26 |
elodilles | hmmm, ok, maybe that could work | 14:27 |
ttx | I think it works, it's just less ideal in terms of duration and where milestones fall | 14:27 |
ttx | question being, what do we care about the most | 14:28 |
elodilles | #action elod to propose another schedule plan (w/ March 22 release date) and let folks / Foundation / TC decide | 14:28 |
ttx | Release week can get busy as we do promotion that involve PTLs etc | 14:28 |
elodilles | ttx: ack | 14:28 |
elodilles | ttx: is this acceptable? ^^^ | 14:28 |
ttx | so making that two difefrent weeks avoids too much collision | 14:28 |
ttx | elodilles: yes. I'd let the TC decide really, once people voice their preference on the reviews | 14:29 |
elodilles | ttx: ack, thanks for the ideas | 14:29 |
elodilles | then let's move on to next topic | 14:29 |
elodilles | #topic Hacking release so late in the cycle? https://review.opendev.org/c/openstack/releases/+/851273 | 14:30 |
elodilles | afaik there were some issues in the past when hacking was released and CI jobs started to break | 14:31 |
ttx | yep, hacking releases we usually push during meilstone-1 | 14:31 |
elodilles | that's why it is best to release early in the cycle | 14:31 |
ttx | so that if they trigger some work it does not conflict with any planned release work | 14:32 |
elodilles | we are just between zed-2 and zed-3 | 14:32 |
armstrong | so the entire code base is moving to 3.10? | 14:32 |
elodilles | armstrong: i don't think so | 14:32 |
elodilles | the patch just drops py36 & py37 support | 14:33 |
elodilles | what every project should have done already | 14:33 |
armstrong | ok thx | 14:34 |
elodilles | and it does other things like 'support flake8 4.x' etc | 14:35 |
elodilles | anyway, the question is, whether we are really late (between zed-2 and zed-3) | 14:36 |
ttx | My vote would be on postponing | 14:36 |
ttx | but it's not a strong opinion | 14:36 |
hberaud | I agree with you to postpone it | 14:36 |
fungi | yes, that seems like it could be generally disruptive so late in the cycle | 14:36 |
elodilles | i agree too, | 14:37 |
ttx | it's more a question of habit. If there is no strong reason to push it late, we should defer it | 14:37 |
fungi | this 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 release | 14:37 |
elodilles | just 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 |
elodilles | but i guess that possibility is weak (fingers crossed) | 14:38 |
elodilles | anyway, we are on consensus as i see | 14:39 |
elodilles | to postpone it to release it early in Antelope cycle | 14:40 |
elodilles | #agreed to postpone Hacking 5.0.0 release to eearly time in Antelope cycle | 14:42 |
elodilles | is this OK ^^^? | 14:42 |
ttx | ++ | 14:43 |
elodilles | ack, then i'll comment on the release patch in behalf of the team | 14:43 |
elodilles | next topic then | 14:43 |
elodilles | #topic Review countdown email contents | 14:43 |
elodilles | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:43 |
elodilles | please review ^^^ | 14:43 |
elodilles | note that i did a bit bigger change in the mail than the usual, | 14:44 |
elodilles | due to the changes in the 1st task | 14: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 |
elodilles | armstrong: ++ | 14:47 |
armstrong | the the "*swift "is this the project level? or a *swift- team within Swift? | 14:48 |
elodilles | the 'swift' deliverable from Swift team :) | 14:49 |
armstrong | ok thx for the clarification | 14:49 |
ttx | lgtm | 14:50 |
hberaud | LGTM | 14:50 |
elodilles | thanks! | 14:50 |
elodilles | #topic Open Discussion | 14:50 |
elodilles | anyone, anything to discuss? | 14:51 |
hberaud | Just a friendly reminder about my PTO | 14:51 |
hberaud | I'll be afk during the next 3 weeks | 14:51 |
elodilles | hberaud: acknowledged, have a nice time off! :) | 14:51 |
hberaud | that's all for me | 14:51 |
hberaud | thanks | 14:51 |
ttx | have a good time off! | 14:52 |
hberaud | thanks | 14:52 |
elodilles | okay, we had the long silence :) | 14:54 |
elodilles | so let's close the meeting! | 14:54 |
elodilles | thanks everyone for participating! o/ | 14:55 |
elodilles | #endmeeting | 14:55 |
opendevmeet | Meeting ended Fri Aug 5 14:55:19 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:55 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-08-05-14.00.html | 14:55 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-08-05-14.00.txt | 14:55 |
opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-08-05-14.00.log.html | 14:55 |
armstrong | thanks | 14:55 |
elodilles | armstrong: ++ | 14:55 |
hberaud | elodilles: thanks | 14:55 |
elodilles | hberaud: ++ | 14:55 |
fungi | oh, 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 script | 15:03 |
fungi | when i try to run what commands it looks to me like that script is running, it just works | 15:04 |
elodilles | fungi: i had the same result so far :/ | 15:10 |
elodilles | i 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 |
fungi | clarkb: 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 failure | 15:14 |
fungi | something has obviously changed between the last pbr tag 3 months ago and now | 15:15 |
fungi | my money's on something related to build isolation and/or recent setuptools behavior changes | 15:15 |
fungi | but the problem seems to be specific to pbr | 15:17 |
fungi | (to pbr building itself i mean, other pbr-using projects aren't hitting this) | 15:17 |
clarkb | seems like that validation script needs to log what failed | 15:18 |
clarkb | the rc value isn't sufficient informatoin | 15: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 |
clarkb | do you need to list build as a build dep somewhere? | 15:20 |
fungi | yeah, i've been assuming that's the reason for the nonzero return | 15:21 |
fungi | but build does seem to exist in the venv | 15:21 |
clarkb | note its a nested venv | 15:21 |
fungi | the logs show it being installed | 15:21 |
fungi | nested in what sense? | 15:21 |
clarkb | is 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 |
clarkb | there are two tox envs there ^ | 15:22 |
fungi | ahh, nested in the filesystem sense | 15:22 |
fungi | is that nested venv something that would be unique to pbr itself, because releases of other stuff aren't hitting this | 15:22 |
clarkb | I don't know. I'm not sure I've ever looked at this validaton script before | 15:23 |
clarkb | I 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 |
clarkb | maybe pbr's venv tox target is not compatible with whatever interface this script assumes | 15:24 |
fungi | i think it's using the releases repo's tox.ini | 15:25 |
fungi | at least from what i was able to trace | 15:25 |
clarkb | for the first tox env yes. But for the second? that .tox dir for the second lives under openstack/pbr | 15:25 |
clarkb | https://zuul.opendev.org/t/openstack/build/58c0b20854574742b390453c40d18447/log/job-output.txt#1161 it does install build to the validate top level tox env | 15:26 |
fungi | oh, yes okay the function in releases calls `tox -e venv --notest` in pbr to create that | 15:26 |
clarkb | But i haven't seen anything doing that in the pbr venv env yet | 15:26 |
*** dviroel is now known as dviroel|lunch | 15:26 | |
fungi | i wonder if that extra step is unnecessary | 15:27 |
clarkb | the pbr venv env installs pbr's test-requirements.txt | 15:27 |
fungi | build doesn't need to be run from a pbr tox venv, it just needs to be run pointed at the pbr source tree | 15:27 |
clarkb | wheel is in that list but not build | 15:27 |
clarkb | I suspect the validte script was updated to use build but not all of the repos that it validates install it properly | 15:27 |
fungi | well, repos shouldn't need to install build themselves. it's like twine in that regard, it doesn't need the project or its deps installed | 15:29 |
clarkb | I agree, but my hunch is that is the interface currently designed | 15:29 |
fungi | build does the installing on its own regardless | 15:29 |
fungi | right, i'm saying i think i can correct this by changing the validate function to call the copy of build it installed | 15:29 |
clarkb | ya that should work | 15:30 |
fungi | clarkb: 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-L87 | 15:33 |
fungi | i hadn't noticed that until this moment | 15:33 |
fungi | looks like that was added by https://review.opendev.org/590476 almost exactly 4 years ago | 15:35 |
clarkb | weird seems useful for all repos | 15:36 |
fungi | well, i think the idea is that you shouldn't need to directly install anything in order to build the project's sdist and wheel | 15:37 |
opendevreview | Jeremy Stanley proposed openstack/releases master: release pbr https://review.opendev.org/c/openstack/releases/+/851972 | 15:39 |
opendevreview | Jeremy Stanley proposed openstack/releases master: Remove PBR-specific validation code https://review.opendev.org/c/openstack/releases/+/852277 | 15:39 |
fungi | hopefully that'll pass | 15:39 |
clarkb | I mean validating an sdist builds is valuable | 15:40 |
fungi | oh, right. this still does | 15:40 |
fungi | the validation is done for all projects, but there was special handling in the build_sdist() function for pbr which i ripped out | 15:41 |
clarkb | its the nested tox that is pbr specific. gotcha | 15:41 |
fungi | it's the only one using that nested venv instead of building from the validation venv | 15:41 |
*** marios|ruck is now known as marios|out | 15:52 | |
elodilles | and it works \o/ | 15:55 |
elodilles | thanks for figuring it out | 15:55 |
elodilles | i was lost in the logs and haven't thought about we have a special handling of pbr :S | 15:56 |
elodilles | especially as it worked locally :-o | 15:57 |
fungi | yeah, 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 builds | 16:03 |
fungi | which of course explains precisely why only pbr was hitting it ;) | 16:04 |
elodilles | yepp :) | 16:06 |
fungi | elodilles: per your comment on 851972, keep in mind that you could set the ptl approved label to carry over on trivial rebases if you like | 16:09 |
*** amoralej is now known as amoralej|off | 16:10 | |
fungi | so 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 valid | 16:10 |
fungi | oh, in fact i think it already is set that way, it's the zuul configuration which is removing it | 16:11 |
fungi | probably the job could be made smarter to accommodate that case, but maybe that's overengineering it | 16:11 |
*** dviroel|lunch is now known as dviroel | 16:30 | |
elodilles | sad update about the PTG: | 19:35 |
elodilles | https://lists.openstack.org/pipermail/openstack-discuss/2022-August/029879.html | 19:36 |
elodilles | :'( | 19:36 |
*** dviroel is now known as dviroel|brb | 19:40 | |
*** dviroel|brb is now known as dviroel | 20:56 | |
*** dviroel is now known as dviroel|out | 21:12 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!