18:00:20 #startmeeting tc 18:00:20 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:20 The meeting name has been set to 'tc' 18:00:24 #chair gouthamr 18:00:24 Current chairs: JayF gouthamr 18:00:28 #chair frickler 18:00:28 Current chairs: JayF frickler gouthamr 18:00:41 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 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. 18:00:57 #topic Roll Call 18:00:59 o/ 18:01:00 tyty JayF; am here, but on the road... 18:01:01 o/ 18:01:03 o/ 18:01:11 o/ 18:01:12 gouthamr and dansmith both indicated they'd be unable to actively participate in today's meeting 18:01:13 o/ 18:01:14 o/ (readonly mode) 18:01:33 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 \o 18:02:06 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 Just let me know when we get there 18:02:28 #topic Action Items from last week 18:02:46 There are two of these on the agenda; first is PyPi Maintainers' cleanup with gouthamr and frickler listed as owners 18:02:50 any update on this first one? 18:03:13 I don't think so 18:03:26 Should the AI remain on the agenda? 18:03:58 maybe i can move it to the regular tracking section 18:04:08 The second item for update is following up on Skyline's graduation, which has gouthamr listed as the owner 18:04:14 I think it is there in tracker 18:04:34 Given gouthamr is interacting through a telephone while on the road, I'll push this update to next week 18:04:34 And there was ml sent which was written very well 18:04:47 I did see the email to the mailing list, that looked good 18:05:07 I'd assume now we are waiting for the skyline team to confirm it 18:05:21 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/VBH4YU7IBY4FXSAZYL4AIB57BTSPQ572/ 18:05:26 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 Thanks for linking that into the minutes, gmann 18:05:37 ++ 18:05:42 moving on to next item 18:05:46 #topic Project Activity Tracking 18:05:47 o/ 18:06:01 This doesn't have an owner listed, is there someone who wants to own this topic? 18:06:31 I can take it if anything 18:06:49 I don't know what to update, it's listed in the agenda without context 18:07:03 noonedeadpunk++ (sorry about the no context) 18:07:13 noonedeadpunk: what update do we have here 18:07:14 i think this has two parts; we have two projects that are in the list of inactive projects 18:07:23 I think it is about Monasca and frezeer 18:07:26 Freezer and monasca are inactive 18:07:27 we need to assess how they're doing this week and next week 18:07:32 Skyline (already referenced) is emerging 18:07:41 for Monasca, I can update 18:07:45 Ah, yeah, we have to determine if they are still inactive by D-2 18:07:56 So for freezer I think it should be left for inactive for 2024.2 18:08:20 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 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZU22KSVDOC46WS6AIS3UHVFVDHOV4KFA/ 18:08:29 ^ for the minutes 18:08:29 I'm not glad with progress there, or better say about backlog that needs to be done 18:08:36 (and my availability) 18:08:50 looks ok to me noonedeadpunk 18:09:02 I'd suggest we send a specific email, re: freezer, similar to that Monasca thread? 18:09:14 Just to ensure the community is updated and knows we followed up for this cycle? 18:09:24 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 JayF: ++ that will be good 18:09:45 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 or we need a resolution for approve the extra time 18:10:03 I think they remain there unless we remove them. 18:10:17 I'll put a note in the minutes about it, we can notify the community (ML) and final decision next week 18:10:23 +1 18:10:23 but we need the TC approval on it for record 18:10:36 And removing from inactive still will need rollcall vote? 18:10:45 As it's a change to the governance repo 18:10:49 Addition/removal requires formal-vote. Nothing in policy indicates we have to have a vote to remain inactive. 18:10:51 yes, formal-vote 18:10:55 Or I'm mixing things here? 18:11:01 ftr I think monasca still has a broken CI in multiple repos 18:11:03 #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#tracking 18:11:28 I cleaned up freezer zuul errors just in case 18:11:52 But CI is still broken for freezer agent 18:12:19 #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 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 or it was a comment somewhere ? 18:13:30 So I think it was smth like - remain as inactive as long as there is a "leader" for the project 18:13:59 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 Yeah.. 18:14:43 noonedeadpunk: I think your proposal is good idea and it will be good to have it 18:14:49 written in doc 18:14:59 Ok, will take care of that then 18:15:02 thanks 18:15:26 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 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 Any policy change holds over for at least a week, yeah? 18:16:04 Or is my calculation of the timing wrong? 18:16:59 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 That's what I thought, just making sure ++ I think my note still applies. 18:17:15 Moving to the next topic 18:17:29 #topic Gate Health Check 18:17:59 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 Are there updates on other projects' of the gate? 18:18:13 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 ++ ty for doing this gmann 18:18:28 ++ good stuff, thanks 18:18:44 those slow marked tests are run in multinode job. 18:18:46 i've proposed backports of that patch - we'll get it merged 18:18:56 also some optimizations in devstack/tempest merged recently 18:18:58 Nice 18:19:08 and there is one notable change from sean on performance optimization 18:19:10 yeah 18:19:21 #link https://review.opendev.org/c/openstack/devstack/+/922630 18:19:49 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 Thanks for all these improvements! 18:20:38 Anything else before I move on? 18:21:02 Thanks to Sean on this part who has worked hard on this and good improvements 18:21:06 that is all from me 18:21:16 #topic 2024.2 TC Tracker 18:21:25 #link https://etherpad.opendev.org/p/tc-2024.2-tracker 18:21:35 Any updates for items in the tracker? 18:22:07 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 I hope in few weeks to be able to present poc for marking project health 18:22:25 please leave your feedback on gerrit and we can discuss there 18:22:26 needs some more polishing 18:23:10 gmann: I'll review that today. Thank you. 18:23:15 thanks 18:23:18 gtema: good luck, it's a tough nut to crack for sure 18:23:36 thanks JayF 18:23:57 Moving on to our final item 18:24:01 #topic Open Discussion / Reviews 18:24:16 #link https://review.opendev.org/q/status:open+repo:openstack/governance 18:24:30 And we had one topic under this that was premade 18:24:44 noonedeadpunk posed a question 18:24:55 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 Yeah, so basically this partially was triggered by masakari and ml regarding it 18:25:40 As 2024.1 release has an alembic db upgrade bug 18:25:49 And upgrades are not tested there 18:26:11 But then there were couple of contributors who were interested in pushing their code 18:26:12 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 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 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 #note clarkb ack, thank you 18:26:48 #undo 18:26:48 Removing item from minutes: #link https://review.opendev.org/q/status:open+repo:openstack/governance 18:26:51 And one contributor pushed whole new driver 18:26:56 clarkb: ack, thank you 18:27:12 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 cs10 is already available but might be further ahead then we want right now 18:27:32 #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 Yeah, but marking as inactive doesn't help 18:27:40 And that was my concern 18:27:52 Yeah, this is... the current core group is 'inactive' 18:28:02 but at least some outside contributors want to be involved and can't due to ^^^ that 18:28:05 As most challenging is to unboard to project interested parties 18:28:09 TC could also choose another PTL if there is a volunteer 18:28:17 yeah, that was my question, does it need core team refactoring ? 18:28:28 We can choose only during elections kinda? 18:28:34 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 ++ 18:29:46 And I think another concerning thing which kinda might fall under this discussion are SIGs. With example of ansible-collections 18:30:27 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 Where most of current cores backed from further maintenance 18:30:32 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 But then it's a sig... So process of onboarding is even more tricky 18:31:20 Yeah, sec, so there was a ML, looking for it now 18:33:52 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/6UDHZ2UCGZB3PHJRH3KS5ITLP7KDXJPM/ 18:34:23 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 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 spotz[m]: I keep updates in this etherpad, please refer that #link https://etherpad.opendev.org/p/2024.2-leaderless 18:35:42 #link https://review.opendev.org/c/openstack/masakari-monitors/+/907140 18:36:24 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 Yeah, I tried to reach to PTL around month ago for different case, got no response... 18:37:08 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 But will do so again 18:37:21 #action noonedeadpunk to reach out (again) to masakari PTL 18:37:45 Yeah, not saying they wanna take leadership 18:38:21 But kinda project technically doesn't fall under "inactive", but it's indeed "cores inactive" which is different substance 18:39:10 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 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 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 I think marking it Inactive and see if current PTL respond or a new leadership or core group can be build 18:40:18 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 I guess for that it should have failing gates 18:40:25 Which is not the case 18:40:32 noonedeadpunk: it might be ok doing that but that kind of hide the inactiveness of project 18:40:39 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 For me project should not be inactive as long as there is community activity around it 18:41:56 And punishing community for misbehaving PTL is kinda bad, imo 18:42:30 noonedeadpunk: you would need to define "community activity around it" 18:42:46 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 Dunno, I really don't like that path 18:42:56 #link https://governance.openstack.org/tc//reference/emerging-technology-and-inactive-projects.html#entry-criteria 18:43:09 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 There's a minimum amount of work required to keep an openstack project running. 18:43:36 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 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 'punishing community' ? do you mean masakari project team or some other group? 18:44:46 I think there is no active maintainer in this case? 18:44:56 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 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 Then why in the world I would try helping out with anything rather then doing things in my GitHub directly 18:45:30 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 Help by... making patches? Which the person has done? 18:45:56 ++ 18:46:15 in this case, where maintainers are not active, I will say become maitainers 18:46:44 What process in policy would we have to enable that? What specific action do we take to get there? 18:46:53 '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 I think that's a material part of the conversation we've gotta have. 18:47:11 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 the tc can appoint a ptl, who can then delegate core reviewer responsibility to themselves or others 18:47:24 fungi: a PTL is already appointed, but absentee 18:47:53 Yes, thanks JayF, you got my concern very precisely 18:47:53 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 noonedeadpunk: I will say, if new people are interested to maintain project, we should onboard them 18:47:56 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 which project are we now talking about? O lost a track 18:48:05 gtema: masakari 18:48:14 * noonedeadpunk also from phone now 18:48:26 thks 18:48:28 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 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 ++ 18:49:08 Is there anything else to mention for open discussion? 18:49:20 Masakari is just an example which struck me 18:49:52 I think we had more cases, where we discouraged individuals from further contributions earlier as well 18:50:17 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 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 survive to the next election I mean 18:50:42 if *Inactive* word sounds negative then we can rename it but purpose should be same 18:50:50 and then they can elect new PTL and move on from that point 18:50:57 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 Yeah, that was smth I had on mind, but kinda... But scalability is really a thing 18:51:27 JayF sure but this isn't problem with every project, right / 18:51:29 TC is hardly having time for itself.. 18:51:29 ? 18:51:37 noonedeadpunk++ 18:51:59 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 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 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 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 and we should be very clear and explicit about this 18:53:33 I guess biggest issue here is a timeline when we can/can not do that 18:53:46 fungi: that is basically the gist of what I'm saying, yeah 18:53:48 Well, ppl are already here to help 18:54:01 anyway, I see Your points about scalability too :) 18:54:09 helping with what needs help: volunteering to run that project 18:54:16 But we are saying - we refuse your help to encourage it next cycle 18:54:45 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 I suggest we continue this conversation outside the meeting 18:55:00 Yeah, thanks 18:55:02 and if the masakari PTL does not respond to noonedeadpunk's email, we bring in the mailing list 18:55:06 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 ++ 18:55:30 we have done it in past for Mistral 18:55:36 the tc has final technical oversight for all official openstack projects 18:55:37 and it was successful 18:56:10 That is a path we can consider once we have more information next week. 18:56:17 Which, I'll note, is a video meeting. 18:56:23 And then document:) 18:56:34 For now though, I'm going to close up the meeting. Thanks everyone o/ 18:56:35 #endmeeting