 Do we have any agenda today? So if we have time at the end, I've got Stephen Belair who's going to be taking over sort of the Envoy VPP work. We'd love to introduce you to the community. Cool. Let's see. I'm looking at the doc. Let's get two minutes. Do you have a quick chat about prevention policy and stuff? I find myself spending a lot of time waiting for reviews that will actually make it so I can merge things. Yeah, sure. I don't know. What would you propose that we do differently? Yeah, that's where I'm stuck. I don't really have a good answer. I feel like there should be some level of code review, right? Absolutely. Yeah, so is the problem that the people from Pinterest aren't reviewing it fast enough or is the problem that once they do that, then we don't do the second stage fast enough? The first part happens, but I just need to bug them to jump on stuff and that's fine. That's no different than, I don't know. But yeah, it's sort of after that, I feel like I end up bugging you all the time for them. Yeah. And I think other folks just kind of go like, I don't know anything about thrift, so I don't want to look at it or maybe it's not quite that bad. I mean, I'm going to be totally honest. I mostly just skim it. I'm not doing a deep code review. So yeah, I don't really know what to do just in the sense that I suppose, like GitHub won't let you submit it without at least someone clicking the button. So even if it's a rubber stamp, that's fine. I guess one of the things that we could discuss is like a general policy where if one of the maintainers is basically building the extension and they've gotten a code review from someone else who's a domain expert, then one of the other maintainers can literally just give it like a three minute skim rubber stamp merge. I don't really have a problem with that, but that's probably worth discussing. I would be good with that. I mean, I have little to contribute towards thrift code reviews, nothing about thrift, but you know, I am happy to obviously give code a pass for basic stylistic things and security bugs and that kind of thing. But I do think that Matt's suggestions sounds more scalable and I mean, again, this is not going to work in general though, because it's not going to apply to new code, which is not maintained by maintainers. Right, you know, and that's something where I think that we're going to have to evolve once that actually happens. We're not, we're not quite there yet. But yeah, I think that there has to be some rubber stamp just in the sense that like one of the nice things about the extension policy is that for organizations like Lyft and like Google and like other people that don't use thrift like one of the beautiful things about this is that I, you know, like, I know that I'm not going to compile that code. So my, like my caring level honestly of like what happens within it is is less than a change to the core code. So I think from a rubber stamp perspective, even just skimming through just to double check that like nothing accidentally leaked, you know, like from the extension to the core code and like should that have been in a separate PR or something like that. So like, I think that makes sense. So I guess maybe what I would suggest is, could you take a look at the verbiage that I wrote in that doc for the existing policy, and then maybe just propose some changes to it that would make it easier for you to go into the current maintainers chat and just say, Hey, can can someone like right now today in the next two hours just like skim this and and rubber stamp. Yeah, make it sort of like the rubber stamping things are like more official. Yeah, exactly. Yeah. Does does that work like is that I think that'll help. Yeah. Okay. All right. Great. Yeah. Yeah, because we're, we're, we're going to be, you know, in similar situations soon in the sense that the people from the double RPC thing just opened an open an issue I think they're going to implement that protocol. So we'll have to have to figure out how that works also. I think it's a little better if it's if you have people who are developing an extension. And then there's just some maintainer who has signed on to like code review. Yes. Then like that person's code review can be the code review. I agree. I agree. Yeah, the the situation that you're in is a little different. And I think we're probably actually just looking ahead. I think we're going to have some other similar situations to what you're doing soon with other extensions. So I think making rubber stamp policy a little more official, I would just be I guess my thinking here is maybe when you when you go through the dock again, and I'm not sure if it's super explicit. I would basically make it really clear like in bold that for the rubber stamp policy to apply all the code has to be within the extensions directory, like if there's any changes to core, like, what actually should say globally is that any changes to core have to be in a separate PR. And I think that would actually make the whole thing a lot more clear, because then we're all on the same page that like this is code that's going to affect everyone. So let's code review it to that standard. And then for code that basically is only in extensions, and just kind of like riffing on this and thinking more for the mythical bots which we don't have, like this would be very easy to actually detect. Like, you know, like when you open the PR, a bot can look at the files that are changed and be like, is it an extension only PR and then actually tag it or something like that. So, so those are just some some random thoughts that come to mind. Okay, I'll take a look at it. Okay, cool. I'm trying. I don't have anything else random. Do you Harvey. No. Okay. Cool. Do you want to talk about VPP briefly, I guess. Yes. Cool. So yeah, we did have a personnel change there as you we noted a couple of meetings ago. So I wanted to give Stephen Blair an opportunity to introduce himself. He'll be picking up that work. And, you know, my understanding is that the plan of record is still to first refactor on voice core to your previous point about high seniors of good so that extensions of that sort are possible in collaboration with both the quick folks at Google and the, and the psyllium guys, and then introduce a VPP extension based upon those extension points. Yeah, I think nothing is right. I think we had some audio hiccup there. Oh, sorry, let's have him go ahead and do that. Stephen, are you there. Yeah, have you heard me. I hear you now. Didn't hear that before. Let me turn my volume up. Sorry about that. Okay. I'll start again. I'm a distinguished engineer at Cisco. Mike check, Ed, am I doing all right here? Can you hear me? Okay. I just came back to Cisco after being gone at a startup for over five years. My background is has been in OS and infrastructure distributed OS with my specialties pretty much in scalability and non blocking architectures. I signed on to this project a little over a week ago it's completely new to me. I actually this whole space is very new to me. I'm a cloud native working in clouds in general. I've done very different stuff for many different years. So I'll have a learning curve, a time to ramp up, but I'm going to pick Ed's brain and he's going to guide me. And I will be asking questions and learning as fast as I can. Great welcome. Yeah, the plan of record I think is still the same and I think some work has even been done since we last talked and that basically boils down to right now in certain parts of the code base we're passing file descriptors around. So in in some sense, the the initial goal is quote simple. It's it's mostly just, you know, kind of relatively self contained but wide reaching refactorings where we're going to hide that file descriptor behind some type of interface. Okay. Yep. So, Your comment was was pretty effortful Matt which is clip out the connect FD method and see what breaks. And that's, and that's exactly what I would do and and we can once you start to make progress we can, you know, we can figure this out but in general we'll ask for incremental code reviews so what we'll probably have for a while is we'll have the FD method and this new things side by side and we'll just incrementally pick it up anyway at pieces, but I actually don't think it's it's that difficult. It's just somewhat somewhat tedious. Once that work is done. It should let us do all this other stuff pretty easily. Okay. Thanks for that guidance. Great. All right, anyone have anything else to chat about with the socket stuff for the refactoring. I've kind of been blocking a lot of forward progress on the UDP stuff awaiting some of this work. Do you think there is any really dependency between them, or should I continue making progress in UDP if I can. I think I think UDP is orthogonal. So I think you can probably make progress without this work. My suggestion would be the following. We do have some things that potentially later we could do in terms of VP integration to help with UDP, but I wouldn't block on any of that shit. Yeah. You know, it's that's quite a bit further down the road. Yeah. I think, I think basic UDP support is actually not that complicated. So it would be nice to just kind of see that happen in isolation. That's great. Yeah, I was just wondering because we kind of put some stuff like this in the original design doc, as far as refactoring out some of the file descriptor stuff as like a step one. And that's why. Yeah, I don't think it's explicitly require just in the sense that we can have the current code expose a UDP file descriptor. And, you know, although there'll definitely be some things that need to get worked on. I think it should mostly fall into place. Okay. Yeah, that was my thinking too. Just have UDP file the UDP file descriptor type or something like that. Yep. Great. Anything else? Going once, going twice. All right. Have a great couple of weeks, everyone. See ya. All right. Thank you.