18:00:07 <gouthamr> #startmeeting tc
18:00:07 <opendevmeet> Meeting started Tue May 21 18:00:07 2024 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:07 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:07 <opendevmeet> The meeting name has been set to 'tc'
18:00:20 <opendevreview> Ghanshyam proposed openstack/governance master: Remove retired project from Inactive project list  https://review.opendev.org/c/openstack/governance/+/920146
18:00:20 <gouthamr> Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct.
18:00:20 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
18:00:26 <gouthamr> #chair frickler
18:00:26 <opendevmeet> Current chairs: frickler gouthamr
18:00:29 <gouthamr> #topic Roll Call
18:00:31 <gmann> o/
18:00:35 <slaweq> o/
18:00:37 <spotz[m]> o/
18:00:40 <dansmith> o/
18:01:40 <frickler> \o
18:01:46 <gtema> o/
18:02:01 <gouthamr> noted absence: noonedeadpunk
18:02:19 <JayF> o/ but distracted
18:02:37 <gouthamr> awesome; we have quorum
18:02:39 <gouthamr> lets get started
18:02:47 <gouthamr> #topic AIs from last week
18:03:05 <gouthamr> PyPi maintainers cleanup lists (gouthamr)
18:03:22 <gouthamr> on this, we identified a loooong list of non-openstackci maintainers that we flagged for cleanup.
18:03:27 <gouthamr> #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L52 (PyPi maintainers flagged for cleanup)
18:03:30 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/64IDNMRS6AUC7T3NBAHF3A7RUCXZUFAG/ ([ptl][tc] OpenStack packages PyPi additional external maintainers audit & cleanup)
18:03:42 <gouthamr> This is a large task - we're cleaning up 207 maintainers off of 146 packages. We can't seem to automate this because of a lack of an API
18:03:54 <gouthamr> We'll keep you posted on how this goes; at best, we'll share responsibilities if fungi is okay so we can spread the risk of RSI between willing TC members
18:04:42 <clarkb> gouthamr: that first link is a list of projects where we do have ownership and can clean things up directly right? How big was the other list where we don't have ownership?
18:04:47 <fungi> yes, the goal was to ask those people to self-remove, but if there's nobody responding them we can discuss how we'll go about doing all the clicking
18:04:58 <clarkb> oh I see its below the first list
18:04:58 <fungi> s/them/then/
18:05:00 <gmann> ++ on doing it on share basis
18:05:39 <gouthamr> clarkb yes, we have that list - sadly, this is long because we did ask folks to self-remove a bunch of times and hasn't happened
18:06:06 <fungi> to be clear on what the ui is like, it's several clicks from the list of projects to get to the collaborators list, and then when you click remove you need to type or paste the username you're removing for confirmation
18:06:20 <gouthamr> and yes, fungi identified some packages where we cant bump maintainers
18:06:29 <fungi> also loading delays, because pypi is a bit sluggish
18:06:32 <gouthamr> packages where we can't remove maintainers: eventlet, kuryr-lib, pymod2pkg, pbrx, git-nit, certbot-dns-openstack, rally-runners, networking-ovs-dpdk, keystoneclient, keystoneauth3, keystoneauth2, prep_source_repos, solum-infra-guestagent, reviewday
18:06:43 <gouthamr> ^ not all of them are under openstack governance
18:06:58 <gmann> because there openstackci is not owner right?
18:07:06 <fungi> right. that was from the full list of ~800 packages that openstackci is a collaborator on
18:07:12 <gmann> i see
18:07:23 <JayF> eventlet, for instance, we wouldn't even want to remove maintainers -- we should probably limit scope for what TC is handling to openstack namespace projects, yeah?
18:07:40 <gmann> one question, should openstackci should be maintainers in openstack governance projects only?
18:07:45 <fungi> and yes, that's the subset where openstackci is a maintainer rather than an owner
18:07:54 <gouthamr> JayF: yes, this list was pulled from the UI
18:07:57 <JayF> gmann: openstackci is the automation user used for all opendev pypi publishing, aiui
18:08:14 <JayF> gmann: I suspect in this case, the naming is just an artifact of it existing prior to opendev's name
18:08:16 <gmann> JayF: ohk then name is confusing.
18:08:27 <fungi> we'd need separate accounts for teh non-openstack projects who are uploading releases to pypi by tagging them in gerrit
18:08:34 <gmann> ++
18:08:36 <fungi> if we switched that one to be openstack-only
18:08:58 <spotz[m]> Weird about the keystone ones?
18:09:13 <fungi> and yes, that account has been in continuous use for basically as long as we've been uploading releases to pypi from our ci/cd systems
18:09:55 <gouthamr> spotz[m]: true; on that, i will reach out to d34dh0r53 and the maintainer
18:09:56 <fungi> spotz[m]: not all that weird when you consider that some of those where either early experiments in openstack that were never realized or were deleted from openstack
18:10:14 <gouthamr> ^ oh, that i didn't know
18:10:15 <gmann> separating is good so that openstack TC can help in cleanup without risk of other projects impact if any
18:10:18 <fungi> i would consider deleting those projects if they have no releases with files
18:10:32 <spotz[m]> If still in use I think we care, but if not yeah it won't matter
18:10:49 <fungi> "back in the day" you had to reserve a project on pypi before you could upload releases, while today it's teh reverse
18:11:29 <fungi> so quite a few projects were reserved on the idea that we'd start developing/releasing them in openstack but then we didn't for various reasons
18:12:41 <fungi> the release team should, i think, have or tell us how to generate a list of the packages we're uploading as openstack deliverable artifacts, and then we can limit the cleanup effort to those
18:12:55 <fungi> should be able to tell us, i mean
18:13:06 <fungi> (not that i'm demanding they do so)
18:14:26 <gouthamr> i see; i can follow up on this
18:14:33 <frickler> mapping deliverables repos to pypi pkg names might be non trivial
18:14:40 <fungi> note that pypi project names don't 1:1 match git repository names for a few reasons (primarily normalization, but also some are renamed in their setup.cfg because the original name was already taken)
18:14:44 <gouthamr> ^ agree
18:14:47 <gouthamr> https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L413
18:14:48 <gmann> or we can do try-cleanup in current list in share basis. this tasks has been open since long and I think we should start cleaning up
18:15:11 <gmann> that seems faster than all other possible steps.
18:15:14 <gouthamr> #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L413 (repos left to review for pypi packages because of metadata issues)
18:15:34 <gouthamr> gmann++
18:16:35 <fungi> frickler: i didn't mean to imply it's trivial, just that the release team probably knows what is needed to do it and can hopefully provide guidance to whomever builds the list
18:16:57 <gouthamr> okay we've spent some time on this..i think we have raised enough awareness among the tc about the ongoing work..
18:17:00 <gouthamr> lets chat on this channel outside of this meeting..
18:17:07 <gouthamr> and follow up on this AI..
18:17:13 <fungi> (e.g. scraping the project.name from the setup.cfg file of each deliverable repo in our projects list)
18:18:01 <gouthamr> gtema: do you have any update on the other AI we had? "Marking inactive projects prominently" (gtema)
18:18:20 <gtema> not yet, sorry
18:18:21 <gouthamr> i was going to suggest moving this one to https://etherpad.opendev.org/p/tc-2024.2-tracker
18:18:59 <gouthamr> nope don't be :) it isn't an urgent issue.. we can track it like we do our usual trackers
18:19:35 <gouthamr> alright; any other thoughts on $topic?
18:20:07 <gmann> I updated status for a few of the one assigned to me
18:20:30 <gouthamr> ty gmann.. /me didn't get around to checking this week
18:20:42 <gouthamr> #topic 2024.2 TC Tracker
18:20:46 <gouthamr> #link https://etherpad.opendev.org/p/tc-2024.2-tracker (Technical Committee activity tracker)
18:21:36 <gouthamr> lots of progress on the "Leaderless projects and inactivity" topic
18:21:57 <gouthamr> ty gmann and all those participating in the reviews and discussions on the ML
18:22:51 <frickler> how long do we want to wait for the charms ptl assignment review to be updated before considering the project inactive?
18:22:58 <gouthamr> :(
18:23:08 <gmann> what we do on this, its been open for a month and no response form volunteer leader? https://review.opendev.org/c/openstack/governance/+/914254
18:23:18 <gmann> frickler: yeah, that one
18:23:35 <gmann> same with Trove, no response on ML on another reminder
18:23:45 <gouthamr> frickler: its a typo in his name that was flagged, seems like an awfully low hanging fruit to knock out .. sigh..
18:23:52 <gmann> I think we should move both projects to inactive state?
18:24:15 <gmann> gouthamr: it is not about typo, it is about how active the volunteer is for leading the project.
18:24:47 <frickler> yes, not reacting on their own changes is a bad indicator on that
18:24:50 <gmann> in past we have seen many cases where we struggled to get activities on projects we have been assigning the volunteer PTL
18:25:11 <gouthamr> i do see activity in the charms repos: https://review.opendev.org/q/charm
18:25:54 <fungi> i think canonical may still be relying on those for some commercial product of theirs, i wonder if jamespage knows what the situation is with its seeming abandonment
18:26:13 <slaweq> maybe we can ask jamespage about charms /
18:26:15 <slaweq> ?
18:26:29 <fungi> maybe they're willing to take further support fully downstream like red hat did with tripleo
18:26:34 <gmann> yeah, it seems Felipe  was active on charm 4 days ago https://review.opendev.org/c/openstack/charm-ceph-osd/+/919794
18:26:35 <slaweq> sorry, fungi was faster :)
18:26:54 <gmann> it seems they might missed the governance change
18:27:21 <slaweq> fungi aren't charms also used in their new product which is sunbeam IIRC?
18:27:59 <fungi> yes, so may be a similar situation to tripleo where they're fine moving support for their legacy stuff downstream until they eol the product
18:28:12 <frickler> there's also some recent updates on the release team tracker, I think we'll need to look at all these teams well before milestone-2 https://etherpad.opendev.org/p/dalmatian-relmgt-tracking#L331
18:28:31 <fungi> i think sunbeam has its own separate charms, but i don't know the full story
18:29:05 <spotz[m]> I know when we approved Sunbeam James said there was enough difference for it to not be the same project
18:29:32 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/903490 (Retire all single charm repositories)
18:29:46 <gouthamr> ^ this is WIP
18:31:21 <gouthamr> maybe we can move this discussion to the ML and seek clarification..
18:31:50 <spotz[m]> +
18:32:05 <gouthamr> #action gouthamr will start a mail thread on the status of the charms project and the PTL volunteer
18:34:34 <gouthamr> there are some open changes on openstack/project-team-guide that can use some review attention:
18:34:45 <gouthamr> #link https://review.opendev.org/q/project:openstack/project-team-guide+status:open (open changes to project-team-guide)
18:35:33 <frickler> + openstack-manuals
18:36:12 <gouthamr> ah good point
18:36:24 <gouthamr> #link https://review.opendev.org/q/project:openstack/openstack-manuals+status:open (open changes on openstack-manuals)
18:37:42 <dansmith> gouthamr: two of those p-t-g changes are waiting on fixes from the submitter
18:38:05 <spotz[m]> I'll check those out
18:38:18 <gouthamr> ty dansmith spotz[m]
18:40:06 <gouthamr> lets move on..
18:40:11 <gouthamr> #topic Open Discussion
18:40:38 <gouthamr> ty slaweq for volunteering to be an election official
18:40:56 <opendevreview> Merged openstack/project-team-guide master: Make the project removal from infra as step#6  https://review.opendev.org/c/openstack/project-team-guide/+/919976
18:40:59 <gouthamr> ianychoi just published the first draft on the dates/process for the next election
18:41:02 <gmann> ++ thanks slaweq
18:41:17 <gouthamr> #link https://review.opendev.org/q/topic:%222025.1-elections%22 (kicking off 2025.1 elections)
18:41:48 <gmann> will check today
18:42:20 <gouthamr> i'm looking to achieve a couple of things with this: 1) real early notification so we don't have the few issues we've had where PTL candidates said they were away or didn't look at the ML
18:42:53 <gouthamr> 2) i wanted to do some more election awareness emails than usual so that we can have a better participation
18:43:17 <gouthamr> we did note that having ~50 people vote was pretty bad for the last TC election..
18:47:01 <opendevreview> Merged openstack/openstack-manuals master: Re-add project data for 2023.1 Antelope  https://review.opendev.org/c/openstack/openstack-manuals/+/916823
18:48:09 <gouthamr> not to pile on to the meeting fatigue :) lets get back to work
18:48:39 <gouthamr> last call for any other discussion to go on record here
18:48:56 <fungi> remember to submit to the summit cfp!
18:48:57 <spotz[m]> Someone needs to AC me until my repos count:)
18:49:03 <fungi> deadline is the end of the month
18:49:28 <JayF> spotz[m]: TC is technically final call on that. I'd suggest you submit a governance change to AC yourself.
18:49:47 <gouthamr> fungi ++
18:50:14 <gouthamr> #link https://2024.openinfraasia.org/ (OpenInfra Summit Asia '24 Call for Papers)
18:51:56 <gouthamr> spotz[m]: like gmann mentioned in the last meeting, we can merge your governance change, and update the tooling and we'll not require an AC change for you..
18:52:39 <gouthamr> but, this can take a bit more time.. can i work with you on that?
18:52:52 <spotz[m]> Sure
18:52:53 * gouthamr will probably ask questions and whip up votes at best
18:54:46 <gouthamr> awesome; if there's nothing else.. i'd like to give you back 5 mins
18:54:53 <gouthamr> thank you all for attending!
18:55:00 <gouthamr> #endmeeting