18:00:20 <JayF> #startmeeting tc
18:00:20 <opendevmeet> Meeting started Tue Jun 25 18:00:20 2024 UTC and is due to finish in 60 minutes.  The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:20 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:20 <opendevmeet> The meeting name has been set to 'tc'
18:00:24 <JayF> #chair gouthamr
18:00:24 <opendevmeet> Current chairs: JayF gouthamr
18:00:28 <JayF> #chair frickler
18:00:28 <opendevmeet> Current chairs: JayF frickler gouthamr
18:00:41 <JayF> 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:48 <JayF> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee.
18:00:57 <JayF> #topic Roll Call
18:00:59 <noonedeadpunk> o/
18:01:00 <gouthamr> tyty JayF; am here, but on the road...
18:01:01 <gouthamr> o/
18:01:03 <slaweq> o/
18:01:11 <gtema> o/
18:01:12 <JayF> gouthamr and dansmith both indicated they'd be unable to actively participate in today's meeting
18:01:13 <gmann> o/
18:01:14 <dansmith> o/ (readonly mode)
18:01:33 <noonedeadpunk> I actually added an item to the agenda late, to open discussion, so feel free to move it to the next one
18:02:00 <frickler> \o
18:02:06 <JayF> Yeah, I see it, it's under open discussion we can have time for it if we have time for it, unless you'd like more of the TC here for that conversation.
18:02:21 <JayF> Just let me know when we get there
18:02:28 <JayF> #topic Action Items from last week
18:02:46 <JayF> There are two of these on the agenda; first is PyPi Maintainers' cleanup with gouthamr and frickler listed as owners
18:02:50 <JayF> any update on this first one?
18:03:13 <frickler> I don't think so
18:03:26 <JayF> Should the AI remain on the agenda?
18:03:58 <gouthamr> maybe i can move it to the regular tracking section
18:04:08 <JayF> The second item for update is following up on Skyline's graduation, which has gouthamr listed as the owner
18:04:14 <gmann> I think it is there in tracker
18:04:34 <JayF> Given gouthamr is interacting through a telephone while on the road, I'll push this update to next week
18:04:34 <noonedeadpunk> And there was ml sent which was written very well
18:04:47 <JayF> I did see the email to the mailing list, that looked good
18:05:07 <noonedeadpunk> I'd assume now we are waiting for the skyline team to confirm it
18:05:21 <gmann> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/VBH4YU7IBY4FXSAZYL4AIB57BTSPQ572/
18:05:26 <JayF> Sounds like it to me; they've done a good job and I'm glad we're getting there to recognize them
18:05:37 <JayF> Thanks for linking that into the minutes, gmann
18:05:37 <noonedeadpunk> ++
18:05:42 <JayF> moving on to next item
18:05:46 <JayF> #topic Project Activity Tracking
18:05:47 <spotz[m]> o/
18:06:01 <JayF> This doesn't have an owner listed, is there someone who wants to own this topic?
18:06:31 <noonedeadpunk> I can take it if anything
18:06:49 <JayF> I don't know what to update, it's listed in the agenda without context
18:07:03 <gouthamr> noonedeadpunk++  (sorry about the no context)
18:07:13 <JayF> noonedeadpunk: what update do we have here
18:07:14 <gouthamr> i think this has two parts; we have two projects that are in  the list of inactive projects
18:07:23 <gmann> I think it is about Monasca and frezeer
18:07:26 <JayF> Freezer and monasca are inactive
18:07:27 <gouthamr> we need to assess how they're doing this week and next week
18:07:32 <JayF> Skyline (already referenced) is emerging
18:07:41 <gmann> for Monasca, I can update
18:07:45 <JayF> Ah, yeah, we have to determine if they are still inactive by D-2
18:07:56 <noonedeadpunk> So for freezer I think it should be left for inactive for 2024.2
18:08:20 <gmann> For Monasca, there is active discussion with current PTL about making it active and release for this cycle, let's see how it goes #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZU22KSVDOC46WS6AIS3UHVFVDHOV4KFA/
18:08:26 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZU22KSVDOC46WS6AIS3UHVFVDHOV4KFA/
18:08:29 <gouthamr> ^ for the minutes
18:08:29 <noonedeadpunk> I'm not glad with progress there, or better say about backlog that needs to be done
18:08:36 <noonedeadpunk> (and my availability)
18:08:50 <gmann> looks ok to me noonedeadpunk
18:09:02 <JayF> I'd suggest we send a specific email, re: freezer, similar to that Monasca thread?
18:09:14 <JayF> Just to ensure the community is updated and knows we followed up for this cycle?
18:09:24 <gmann> but we do not have any formal way to approve the extra time any Inactive project need. should we do it just as a vote in meeting?
18:09:34 <gmann> JayF: ++ that will be good
18:09:45 <JayF> I think it's important to show consensus, I don't think it's ever a good idea to rely on IRC-meeting-votes for anything official :)
18:09:54 <gmann> or we need a resolution for approve the extra time
18:10:03 <JayF> I think they remain there unless we remove them.
18:10:17 <JayF> I'll put a note in the minutes about it, we can notify the community (ML) and final decision next week
18:10:23 <gouthamr> +1
18:10:23 <gmann> but we need the TC approval on it for record
18:10:36 <noonedeadpunk> And removing from inactive still will need rollcall vote?
18:10:45 <noonedeadpunk> As it's a change to the governance repo
18:10:49 <JayF> Addition/removal requires formal-vote. Nothing in policy indicates we have to have a vote to remain inactive.
18:10:51 <gmann> yes, formal-vote
18:10:55 <noonedeadpunk> Or I'm mixing things here?
18:11:01 <frickler> ftr I think monasca still has a broken CI in multiple repos
18:11:03 <JayF> #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#tracking
18:11:28 <noonedeadpunk> I cleaned up freezer zuul errors just in case
18:11:52 <noonedeadpunk> But CI is still broken for freezer agent
18:12:19 <JayF> #note Freezer is likely to remain inactive this cycle. Monasca is trying to figure out a path to being in this release. TC will make final decision next week after consulting community.
18:12:25 <gmann> noonedeadpunk: you have proposal up for this extra time things for Inactive project. was there any way mentioned about how to record the approval or just not remove it from inactive and not retier it
18:13:23 <gmann> or it was a comment somewhere ?
18:13:30 <noonedeadpunk> So I think it was smth like - remain as inactive as long as there is a "leader" for the project
18:13:59 <gmann> noonedeadpunk: ah this comment, #link https://review.opendev.org/c/openstack/governance/+/921500/1..3/reference/emerging-technology-and-inactive-projects.rst#b102
18:14:08 <noonedeadpunk> Yeah..
18:14:43 <gmann> noonedeadpunk: I think your proposal is good idea and it will be good to have it
18:14:49 <gmann> written in doc
18:14:59 <noonedeadpunk> Ok, will take care of that then
18:15:02 <gmann> thanks
18:15:26 <JayF> I think that'd be nice, but also won't apply for this cycle as it can't land before D-2, yeah?
18:15:47 <JayF> D-2 is a week from Thursday (on a US holiday, July 4), and that means we have to adjudicate inactive projects by next meeting.
18:15:53 <JayF> Any policy change holds over for at least a week, yeah?
18:16:04 <JayF> Or is my calculation of the timing wrong?
18:16:59 <gmann> it can be done separately, we can approve freezer extension about Inactive project deadline in next meeting and write something in doc for future ref with no rush
18:17:13 <JayF> That's what I thought, just making sure ++ I think my note still applies.
18:17:15 <JayF> Moving to the next topic
18:17:29 <JayF> #topic Gate Health Check
18:17:59 <JayF> Ironic had to do a bit of a dance with SNMP libraries, and revert something from requirements, thanks to that team for it.
18:18:10 <JayF> Are there updates on other projects' of the gate?
18:18:13 <gmann> one update, as discussed in previous meeting, I have skipped the slow marked tests from ceph job #link https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/922443
18:18:26 <gouthamr> ++ ty for doing this gmann
18:18:28 <JayF> ++ good stuff, thanks
18:18:44 <gmann> those slow marked tests are run in multinode job.
18:18:46 <gouthamr> i've proposed backports of that patch - we'll get it merged
18:18:56 <frickler> also some optimizations in devstack/tempest merged recently
18:18:58 <noonedeadpunk> Nice
18:19:08 <gmann> and there is one notable change from sean on performance optimization
18:19:10 <gmann> yeah
18:19:21 <gmann> #link https://review.opendev.org/c/openstack/devstack/+/922630
18:19:49 <gmann> this will improve overall performance and we can try the concurrency as 6 in some of the job and see how it goes
18:20:20 <JayF> Thanks for all these improvements!
18:20:38 <JayF> Anything else before I move on?
18:21:02 <gmann> Thanks to Sean on this part who has worked hard on this and good improvements
18:21:06 <gmann> that is all from me
18:21:16 <JayF> #topic 2024.2 TC Tracker
18:21:25 <JayF> #link https://etherpad.opendev.org/p/tc-2024.2-tracker
18:21:35 <JayF> Any updates for items in the tracker?
18:22:07 <gmann> I think most of you have seen but I would like to mention about affiliation diversity handling proposal #link https://review.opendev.org/c/openstack/governance/+/922512
18:22:19 <gtema> I hope in few weeks to be able to present poc for marking project health
18:22:25 <gmann> please leave your feedback on gerrit and we can discuss there
18:22:26 <gtema> needs some more polishing
18:23:10 <JayF> gmann: I'll review that today. Thank you.
18:23:15 <gmann> thanks
18:23:18 <JayF> gtema: good luck, it's a tough nut to crack for sure
18:23:36 <gtema> thanks JayF
18:23:57 <JayF> Moving on to our final item
18:24:01 <JayF> #topic Open Discussion / Reviews
18:24:16 <JayF> #link https://review.opendev.org/q/status:open+repo:openstack/governance
18:24:30 <JayF> And we had one topic under this that was premade
18:24:44 <JayF> noonedeadpunk posed a question
18:24:55 <JayF> What to do with projects/SIGs that are considered as active, there's a community interest in contributing to them, but it's very hard to land a change due to Cores/PTL being not very active
18:25:18 <noonedeadpunk> Yeah, so basically this partially was triggered by masakari and ml regarding it
18:25:40 <noonedeadpunk> As 2024.1 release has an alembic db upgrade bug
18:25:49 <noonedeadpunk> And upgrades are not tested there
18:26:11 <noonedeadpunk> But then there were couple of contributors who were interested in pushing their code
18:26:12 <clarkb> CentOS 8 Stream is EOL and packages were automatically claered out of our mirror by deletions upstream. This is impacting a number of projects (glance I know of for example) trying to run fips jobs. I mentioned this in the qa meeting today and I'm hoping they'll have more guidance (maybe switch jobs to c9s?) but want to amke sure people are aware of that. I'm currently in the
18:26:14 <clarkb> process of removing the c8s test nodes entirely to avoid wasted resources on building images and starting jobs that fail 100% of the time
18:26:16 <JayF> This is a really tough situation when it happens. Does anyone know if we have any governance precedent for these kinda issues?
18:26:44 <JayF> #note clarkb ack, thank you
18:26:48 <JayF> #undo
18:26:48 <opendevmeet> Removing item from minutes: #link https://review.opendev.org/q/status:open+repo:openstack/governance
18:26:51 <noonedeadpunk> And one contributor pushed whole new driver
18:26:56 <JayF> clarkb: ack, thank you
18:27:12 <gmann> noonedeadpunk: I think this is one of the important part of saying project is Active, if project is not reviewing the incoming requests then we should discuss about marking it Inactive
18:27:22 <spotz[m]> cs10 is already available but might be further ahead then we want right now
18:27:32 <JayF> #note clarkb informed the TC that FIPs jobs are failing due to them running on now-EOL CentOS 8 Stream. Projects must take action to keep these jobs.
18:27:33 <noonedeadpunk> Yeah, but marking as inactive doesn't help
18:27:40 <noonedeadpunk> And that was my concern
18:27:52 <JayF> Yeah, this is... the current core group is 'inactive'
18:28:02 <JayF> but at least some outside contributors want to be involved and can't due to ^^^ that
18:28:05 <noonedeadpunk> As most challenging is to unboard to project interested parties
18:28:09 <frickler> TC could also choose another PTL if there is a volunteer
18:28:17 <gmann> yeah, that was my question, does it need core team refactoring ?
18:28:28 <noonedeadpunk> We can choose only during elections kinda?
18:28:34 <JayF> it's tough from two perspectives; because we do need a trusted stacker to review stuff from a cultural/security standpoint even beyond "working"
18:28:43 <noonedeadpunk> ++
18:29:46 <noonedeadpunk> And I think another concerning thing which kinda might fall under this discussion are SIGs. With example of ansible-collections
18:30:27 <JayF> I'm unsure how to handle this situation from any level TBH. Not sure what our polices that may already exist... but even from a basic standpoint, I'm not sure what the right resolution is
18:30:30 <noonedeadpunk> Where most of current cores backed from further maintenance
18:30:32 <gmann> but you mentioned that there are new people interested in contributing ? is it a few thing to contribute or maintaining this project ?
18:30:54 <noonedeadpunk> But then it's a sig... So process of onboarding is even more tricky
18:31:20 <noonedeadpunk> Yeah, sec, so there was a ML, looking for it now
18:33:52 <noonedeadpunk> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/6UDHZ2UCGZB3PHJRH3KS5ITLP7KDXJPM/
18:34:23 <spotz[m]> Did we ever finalize all the PTLs though? I mean Charms was only done a few weeks ago if a missing PTL is the issue
18:34:41 <noonedeadpunk> And a patch that was discussed before in ml (like previous cycle), person has come up with proposal, but silence after that
18:35:40 <gmann> spotz[m]: I keep updates in this etherpad, please refer that #link https://etherpad.opendev.org/p/2024.2-leaderless
18:35:42 <noonedeadpunk> #link https://review.opendev.org/c/openstack/masakari-monitors/+/907140
18:36:24 <JayF> I see sorta, two actions we need to take outta this potentially: 1) A TC rep needs to reach out to this user and PTL to try and see if we can get a response and 2) We need to consider, at a more general level, what to do for this pattern of situation: PTL/existing cores inactive with willing-but-onboarding-needed potential contributors waiting in the wings.
18:37:02 <noonedeadpunk> Yeah, I tried to reach to PTL around month ago for different case, got no response...
18:37:08 <JayF> Although reading that ML post, I'm not sure the contributor in this specific case is interested in long-term-maintenance/leadership of the project.
18:37:08 <noonedeadpunk> But will do so again
18:37:21 <JayF> #action noonedeadpunk to reach out (again) to masakari PTL
18:37:45 <noonedeadpunk> Yeah, not saying they wanna take leadership
18:38:21 <noonedeadpunk> But kinda project technically doesn't fall under "inactive", but it's indeed "cores inactive" which is different substance
18:39:10 <gmann> noonedeadpunk: I think this is how we did for Mistral also. we marked it Inactive where previous core group was not maintainting it. a new core group came forward and maintainted it
18:39:10 <JayF> Yeah, it gets into a place like I've said in the past, where for smaller/less active projects something less heavy than openstack might be a useful model since those models can often handle more intermittent contribution than we generally do (likely at the expense of it just ... not working more often)
18:39:30 <noonedeadpunk> So we should somehow get a way for community to fix things in case of cores inactive without marking project as inactive
18:39:47 <gmann> I think marking it Inactive and see if current PTL respond or a new leadership or core group can be build
18:40:18 <JayF> noonedeadpunk: yeah, the other proposal in this direction which seems like it might make sense here is a small projects sig (bad name, and probably not a sig)
18:40:20 <noonedeadpunk> I guess for that it should have failing gates
18:40:25 <noonedeadpunk> Which is not the case
18:40:32 <gmann> noonedeadpunk: it might be ok doing that but that kind of hide the inactiveness of project
18:40:39 <JayF> noonedeadpunk: but a shared group of people who help with keeping CI running and patches flowing for projects that otherwise would have very little individual attention
18:41:37 <noonedeadpunk> For me project should not be inactive as long as there is community activity around it
18:41:56 <noonedeadpunk> And punishing community for misbehaving PTL is kinda bad, imo
18:42:30 <gtema> noonedeadpunk: you would need to define "community activity around it"
18:42:46 <noonedeadpunk> About other place for project... Well... If I fork it to my GitHub and maintain myself... Doesn't help ecosystem anyway kinda...
18:42:55 <noonedeadpunk> Dunno, I really don't like that path
18:42:56 <gmann> #link https://governance.openstack.org/tc//reference/emerging-technology-and-inactive-projects.html#entry-criteria
18:43:09 <JayF> I agree re: not punishing community for absentee PTL, except I'd say I'm skeptical one person's interest implies there's an entire community being disenfranchised.
18:43:27 <JayF> There's a minimum amount of work required to keep an openstack project running.
18:43:36 <gmann> these are the criteria for going Project Inactive, if changes are merged there then we do not need PTL to be active but that is not case here right?
18:44:08 <JayF> Yeah, in the short term immediate problem is: patches are being pushed, no engaged cores/ptls to even give feedback on them
18:44:30 <gmann> 'punishing community' ? do you mean masakari project team or some other group?
18:44:46 <gmann> I think there is no active maintainer in this case?
18:44:56 <noonedeadpunk> Well, let's put it this way. If the project is not released and I am relying heavily on it and ready to help out, but being pushed back by "the process x is extremely confusing experience
18:44:58 <JayF> gmann: I read that as punishing the users of the project (by not releasing) and interested non-core-contributors (like the ML-poster) by not merging changes
18:45:27 <noonedeadpunk> Then why in the world I would try helping out with anything rather then doing things in my GitHub directly
18:45:30 <gmann> JayF: that is where we expect them to come forward and help current maintenance team or take over to make it active
18:45:48 <JayF> Help by... making patches? Which the person has done?
18:45:56 <noonedeadpunk> ++
18:46:15 <gmann> in this case, where maintainers are not active, I will say become maitainers
18:46:44 <JayF> What process in policy would we have to enable that? What specific action do we take to get there?
18:46:53 <gmann> 'you are using it or need it and not much active maitainters  to land your fixes then come farword to maintain it'
18:46:56 <JayF> I think that's a material part of the conversation we've gotta have.
18:47:11 <noonedeadpunk> I'm not saying making any decisions now, but wanted to raise that and hear out opinions . And maybe think on that perspective a bit :)
18:47:14 <fungi> the tc can appoint a ptl, who can then delegate core reviewer responsibility to themselves or others
18:47:24 <JayF> fungi: a PTL is already appointed, but absentee
18:47:53 <noonedeadpunk> Yes, thanks JayF, you got my concern very precisely
18:47:53 <JayF> noonedeadpunk: yeah, I'm not saying we solve it now, just trying to ... sharpen  the scope of the problem in terms of things TC can do :)
18:47:54 <gmann> noonedeadpunk: I will say, if new people are interested to maintain project, we should onboard them
18:47:56 <fungi> yes, in this case i guess what is missing is a process by which the tc can replace the ptl when they disappear, without waiting for the next election
18:47:58 <gtema> which project are we now talking about? O lost a track
18:48:05 <JayF> gtema: masakari
18:48:14 * noonedeadpunk also from phone now
18:48:26 <gtema> thks
18:48:28 <gmann> and if no active maintainers and things are not merging there then mark it Inactive for better communication to wider audience to help it
18:48:41 <JayF> I think there's a lot to discuss here, and those discussions don't have to all happen in a meeting. I'd suggest we keep this dialog going in search of a solution over the next couple of weeks.
18:48:53 <noonedeadpunk> ++
18:49:08 <JayF> Is there anything else to mention for open discussion?
18:49:20 <noonedeadpunk> Masakari is just an example which struck me
18:49:52 <noonedeadpunk> I think we had more cases, where we discouraged individuals from further contributions earlier as well
18:50:17 <gmann> IMO, marking project Inactive is not bad way but a good communication to say 'this project need help and who are using it should come forward'
18:50:24 <slaweq> can we add (part) of the TC to be kind of temporary cores in the project to help new maintainersto survive to the
18:50:29 <slaweq> survive to the next election I mean
18:50:42 <gmann> if *Inactive* word sounds negative then we can rename it but purpose should be same
18:50:50 <slaweq> and then they can elect new PTL and move on from that point
18:50:57 <JayF> slaweq: I am willing from a policy standpoint to say I'd be OK with that, but I don't think it's a scalable solution to this general problemset.
18:51:16 <noonedeadpunk> Yeah, that was smth I had on mind, but kinda... But scalability is really a thing
18:51:27 <slaweq> JayF sure but this isn't problem with every project, right /
18:51:29 <noonedeadpunk> TC is hardly having time for itself..
18:51:29 <slaweq> ?
18:51:37 <JayF> noonedeadpunk++
18:51:59 <JayF> slaweq: I am concerned if we ... remove some of the supply-side pressure for maintainers, it might *become* a more common problem.
18:52:31 <JayF> slaweq: I am a firm believer in supply/demand effects in OSS ecosystems; as long as we supply working releases invested parties are not as motivated to assist in keeping the lights on
18:53:06 <slaweq> well, this would be just temporary until next election, if then there wouldn't be new and active PTL elected, project should go to the 'inactive' phase IMHO
18:53:24 <fungi> sometimes it may be necessary to allow a disaster to unfold in order for the people impacted to realize that they really should have been helping prevent it
18:53:31 <slaweq> and we should be very clear and explicit about this
18:53:33 <noonedeadpunk> I guess biggest issue here is a timeline when we can/can not do that
18:53:46 <JayF> fungi: that is basically the gist of what I'm saying, yeah
18:53:48 <noonedeadpunk> Well, ppl are already here to help
18:54:01 <slaweq> anyway, I see Your points about scalability too :)
18:54:09 <fungi> helping with what needs help: volunteering to run that project
18:54:16 <noonedeadpunk> But we are saying - we refuse your help to encourage it next cycle
18:54:45 <JayF> I started this discussion by saying I'm not sure what a good solution would be; and I think we're going to end there (for now).
18:54:50 <JayF> I suggest we continue this conversation outside the meeting
18:55:00 <noonedeadpunk> Yeah, thanks
18:55:02 <JayF> and if the masakari PTL does not respond to noonedeadpunk's email, we bring in the mailing list
18:55:06 <fungi> the tc does have the ability to add anyone they like to core reviewer groups, even if it's not explicitly stated in governance it's not disallowed either
18:55:18 <slaweq> ++
18:55:30 <gmann> we have done it in past for Mistral
18:55:36 <fungi> the tc has final technical oversight for all official openstack projects
18:55:37 <gmann> and it was successful
18:56:10 <JayF> That is a path we can consider once we have more information next week.
18:56:17 <JayF> Which, I'll note, is a video meeting.
18:56:23 <noonedeadpunk> And then document:)
18:56:34 <JayF> For now though, I'm going to close up the meeting. Thanks everyone o/
18:56:35 <JayF> #endmeeting