14:00:36 <elodilles> #startmeeting releaseteam
14:00:36 <opendevmeet> Meeting started Fri Jan 10 14:00:36 2025 UTC and is due to finish in 60 minutes.  The chair is elodilles. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:36 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:36 <opendevmeet> The meeting name has been set to 'releaseteam'
14:00:48 <elodilles> Ping list: release-team
14:00:58 <elodilles> #link https://etherpad.opendev.org/p/epoxy-relmgt-tracking
14:00:59 <armstrong> o/
14:01:00 <elodilles> o/
14:01:08 <ttx> o/
14:03:23 <elodilles> so we are around line 184
14:04:00 <elodilles> let's start then
14:04:14 <elodilles> #topic Review task completion
14:04:26 <elodilles> 1st task was:
14:04:33 <elodilles> 'Generate a list of all cycle-with-intermediary libraries which did not release since the YYYY-MM-DD date of milestone-1. (elod)'
14:04:48 <elodilles> #link https://review.opendev.org/q/topic:epoxy-milestone-2
14:05:30 <elodilles> a bit less than 3rd part of them are missing reviews,
14:06:00 <elodilles> some still waits for update or further team member reviews
14:06:21 <elodilles> or 2nd +2s
14:07:48 <elodilles> I'll double check the ones that has no response from team after the meeting and I guess we can release them if there's no issue with them
14:07:57 <armstrong> Ok I will take a look and review some
14:08:11 <elodilles> armstrong: thanks o/
14:09:01 <elodilles> there is a follow-up task for this in next weeks tasks, so this should be good
14:09:08 <elodilles> oh one question though:
14:09:23 <elodilles> i've seen a release patch for python-freezerclient
14:09:36 <elodilles> #link https://review.opendev.org/c/openstack/releases/+/938780
14:09:40 <elodilles> commented on it ^^^
14:10:07 <elodilles> is freezer officially back in this cycle?
14:10:34 <fungi> it's still listed as inactive
14:10:35 <elodilles> because in that case i think all its deliverables should be added
14:10:45 <fungi> #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects
14:10:54 * ttx looks up log
14:11:30 <elodilles> so either we shouldn't add or add all necessary freezer deliverables
14:11:46 <ttx> See https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2025-01-06.log.html
14:12:11 <ttx> So it's a bit uncertain
14:13:00 <elodilles> thanks for the link
14:13:57 <elodilles> then the question is: should we add freezer deliverables, or just leave it to freezer folks to tag the releases manually (if we are not sure about its active state)
14:14:35 <elodilles> opinions?
14:14:43 <fungi> probably the latter unless/until the tc takes it out of inactive state?
14:15:19 <ttx> I think we give noonedeadpunk a bit more time to decide if it will be revived
14:15:41 <ttx> But yes we need closure on this well before milestone-3
14:15:48 <elodilles> +1
14:16:39 <fungi> yeah, i mean, this is about the point in the cycle where if the tc hasn't decided then it's presumably deferred until next cycle, logistically
14:17:13 <elodilles> yepp
14:17:54 <fungi> this week was their official deadline according to the schedule
14:18:29 <elodilles> but the release can be done anyway, it just won't show up in the coordinated release
14:18:35 <fungi> right
14:19:16 <elodilles> anyway, i'm adding a topic regarding this to next week's meeting, for a follow up
14:20:13 <elodilles> OK, move on then
14:20:49 <elodilles> 2nd task was: 'To catch if there are acl issues in newly created repositories, run tools/aclissues.py (ttx)'
14:21:00 <elodilles> openstack/whitebox-tempest-plugin (Quality Assurance) in openstack/whitebox-tempest-plugin.config
14:21:02 <ttx> I ran the check and spotted one glitch
14:21:19 <ttx> and proposed the project-config fix for it
14:21:36 <noonedeadpunk> fwiw, I've pushed freezer client patch yesterday
14:21:39 <ttx> #link https://review.opendev.org/c/openstack/project-config/+/938887
14:21:39 <elodilles> this one i guess:
14:21:42 <elodilles> ^^^
14:22:54 <ttx> so we are all set
14:23:12 <elodilles> noonedeadpunk: i've seen it and commented on it
14:23:28 <noonedeadpunk> aha, ok, let me check then :)
14:23:43 <elodilles> noonedeadpunk: feel free to ping us anytime to discuss the thing if needed
14:24:18 <noonedeadpunk> elodilles: so I feel it being like a chicken-egg situation right now
14:24:43 <noonedeadpunk> for freezer to become active - a TC resolution should be made
14:25:12 <noonedeadpunk> but it's already a deadline for clients, and if client is not gonna be released - TC will point to absent release for lcient
14:25:22 <elodilles> noonedeadpunk: i think we are happy to add the deliverables (all of them at once) to deliverables/epoxy if you/TC ACKs they are ready to be part of 2025.1 Epoxy
14:25:25 <fungi> the tc tells the release managers which projects will be included in the coordinated release
14:26:06 <noonedeadpunk> ok, so basically it should be TC resolution first to state that project is active...
14:26:19 <ttx> yeah, and the sooner we know the better :)
14:26:43 <noonedeadpunk> I just think I saw some different prespective, that a release could be a flag to TC... but I could misunderstood
14:27:12 <noonedeadpunk> so right now CI is green, though a work is ongoing for some bigger re-factoring of the service
14:27:56 <noonedeadpunk> (which potentially will be ready only by 2025.2)
14:28:10 <noonedeadpunk> ok. then I'll go and propose patch to governance I guess
14:28:30 <elodilles> noonedeadpunk: as I said some line above, if you are not that sure that freezer can be part of 2025.1, then there is the option to manually release the deliverables
14:29:12 <fungi> yes, the projects' deliverables can presumably have releases this cycle, even if they're not officially included as part of the coordinated 2025.1/epoxy release
14:29:49 <fungi> being inactive doesn't necessarily block release requests for those deliverables
14:29:49 <elodilles> tagging rights need to be granted for a freezer core, and the tagging will trigger the release jobs. the releases will happen, but the deliverables won't be listed under 2025.1 Epoxy
14:30:30 <fungi> or manual releasing like that i guess, right
14:31:38 <elodilles> anyway, the sooner we have a more clear view / decision, is the better :) we don't have to decide on this meeting i guess :)
14:32:24 <elodilles> so let's move on now - noonedeadpunk feel free to ping us any time next week if you have any further question
14:32:28 <noonedeadpunk> ++
14:32:41 <elodilles> ttx: about whitebox-tempest-plugin
14:32:55 <elodilles> is that added to releases repository somewhere?
14:33:11 <elodilles> ir will that be the next step to add?
14:33:30 <ttx> it was already there
14:33:40 <elodilles> hmmm. i don't find it
14:34:11 <ttx> in _independent?
14:34:15 <elodilles> ah, there it is
14:34:26 <elodilles> sorry then, then all good
14:35:55 <elodilles> OK, then this task is also covered
14:36:13 <elodilles> well, the topic as well
14:36:17 <elodilles> so next topic:
14:36:28 <elodilles> #topic Assign R-11 week tasks
14:36:59 <elodilles> ttx: could you chair next week's meeting?
14:37:33 <ttx> yes
14:38:19 <elodilles> i've added my name to the release cycle schedule planning task, but feel free to hijack it if you have already some timeplan in your mind o:)
14:38:30 <elodilles> ttx: thanks o/
14:38:31 <ttx> was wondering if we have covered the "OpenStackSDK, Monasca and Freezer" task from this week
14:38:38 <ttx> We discussed Freezer...
14:38:58 <ttx> so maybe we need to push it back to next week?
14:39:04 <elodilles> ttx: oh sorry
14:39:11 <elodilles> #undo
14:39:11 <opendevmeet> Removing item from minutes: #topic Assign R-11 week tasks
14:39:28 <elodilles> missed it...
14:39:31 <elodilles> so:
14:39:37 <elodilles> 'Chase OpenStackSDK, Monasca and Freezer PTLs re: deliverables defined in governance but not in deliverable files (see above)'
14:40:02 <ttx> OpenStackSDK is kind of covered with the recent addition of codegenerator, openapi
14:40:23 <ttx> https://review.opendev.org/c/openstack/releases/+/938668
14:40:29 <ttx> That leaves Monasca
14:41:02 <ttx> which I think is about to be removed
14:41:37 <elodilles> you mean from project-config repository, right?
14:41:51 <ttx> From governance. we should probably add a check in a future week that it's been indeed cleaned up
14:42:11 <ttx> I'll add it to a future week.
14:42:22 <elodilles> ttx: ACK, thanks.
14:42:38 <elodilles> I can prepare a patch for that if needed
14:42:54 <fungi> i haven't seen changes yet to retire the monasca deliverables, but i do expect they're on the way soon yes
14:43:01 <elodilles> if you haven't done yet
14:43:37 <ttx> I think it's a decision for the TC to make
14:43:57 <ttx> OK I think we can move on :)
14:44:22 <elodilles> ACK, thanks!
14:44:30 <elodilles> #topic Assign R-11 week tasks
14:44:41 <elodilles> all tasks taken
14:45:09 <elodilles> #topic Review weekly countdown email
14:45:22 <elodilles> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails
14:45:25 <elodilles> please review ^^^
14:47:31 <ttx> lgtm
14:47:38 <elodilles> ++
14:47:52 <elodilles> will send it after the meeting
14:48:20 <elodilles> #topic Open Discussion
14:48:29 <elodilles> anything to discuss?
14:49:07 <fungi> #link https://review.opendev.org/938510 Allow pre-releases for independent deliverables
14:49:41 <fungi> i pushed that up for debate, i don't feel super strongly that it's needed, but we had a case where it would be nice
14:49:52 <elodilles> i've had only a quick glance at the patch, i don't know the history of this o:)
14:50:16 <ttx> I commented...
14:50:50 <fungi> in particular, pbr's use as a setuptools plugin (setup_requires/build-backend) makes it very hard to test from source in packages that use it
14:50:55 <ttx> I just have a very hard time remembering, but that corner case definitely rings a bell
14:51:09 <elodilles> i'm also OK to +2 this if needed. we can revert if it turns out as a bad decision o:)
14:51:38 <fungi> ttx: was my answer in the comment yesterday what you were thinking of, or was it something else?
14:51:47 <ttx> My memory is definitely associated with the ghost of Monty telling me we should really not allow that
14:52:15 <ttx> ah, missed the answer, checking
14:52:56 <fungi> basically, yes pre-releases were a problem before all our supported platforms had pip 1.4 or later (which probably wasn't until at least 2016)
14:52:57 <elodilles> spooky :S
14:53:36 <ttx> OK, that sounds like the thing I remember (wrong version being installed and all)
14:54:24 <ttx> We should check that auto-proposal of global requirements constraints updates skip first, probably
14:54:52 <fungi> but it did remind me, as i commented, that we probably want the constraints update proposal job to not run for pre-release versions (which may already be the case since the pre-release and release pipelines in zuul are separate)
14:56:21 <fungi> yeah, looks like propose-update-constraints runs from the release pipeline specifically
14:56:54 <fungi> #link https://zuul.opendev.org/t/openstack/builds?job_name=propose-update-constraints&skip=0
14:57:14 <fungi> oh! we do also run it in the pre-release pipeline
14:57:44 <fungi> #link https://zuul.opendev.org/t/openstack/builds?job_name=propose-update-constraints&pipeline=pre-release&skip=0
14:58:25 <fungi> so it's possible we're already putting pre-releases of things in constraints, just not independent release libs
14:59:09 <ttx> fungi: yes but cycle-with-rc things are usually not use in dependencies
14:59:15 <ttx> used*
14:59:33 <elodilles> beta/milestone release are used though
14:59:38 <ttx> We require all libraries to be cycle-with-intermediary for that reason
14:59:41 <fungi> i see pyeclib there, for example, which is in constraints
15:00:39 <ttx> I remember a library using pre-release versioning was a bad idea. maybe no longer since 2016
15:01:09 <ttx> so that's why we forced all libs to be cycle-with-intermediary
15:01:48 <fungi> i don't want to drag the meeting out, just bringing that change to everyone's attention, we can discuss async later
15:02:47 <elodilles> fungi: ACK
15:02:56 <elodilles> let's end the meeting then
15:03:09 <elodilles> and we can discuss this further if needed after the meeting
15:03:16 <elodilles> thanks everyone o/
15:03:20 <elodilles> #endmeeting