 All right, well, I guess we can get going So quick announcement the the CFP for both of the Kube cons for winter opened. So that's the one in Seattle In December and then there's one in China in November so Would be really great to get to get more people speaking. So if you're Out there interested in in talking about stuff Would be great to do a do a proposal. So let me know if you need any help on anything Or I'm sure you can talk to Chris also But it's a it's a good opportunity and particularly if you're an end user You know, I think those talks they're super super popular All right, so I Guess I just wanted to talk through the extension policy. So there's a link in the meeting notes doc Oops, sorry phone is ringing here for some reason So so the idea behind the extension policy for people that haven't actually read it is that we have kind of an increasing number of Organizations that would like to add extensions to the repo and it's Eclipsing I would say our ability to do quality code reviews and Figure out how to manage this entire situation. So I Put together kind of a strong proposal. There's no there's no perfect solution here I'll just briefly summarize it So the idea behind the proposal is that for the extensions that are in the repo We would like to maintain the same quality bar Effectively that we're using for all of the core code. So that means style testing code reviews All of that. So, you know, the idea being that the extensions in the repo to Extent that we can guarantee it our production quality release candidate quality That obviously means that we have to have people that can do those code reviews and they actually care about them So the proposal that I put together Is basically saying that in order to get an extension in the repo one of the existing maintainers Effectively has to sponsor it so that maintainer would kind of shepherd the process like make sure that code reviews are happening Well, and then what we would do is eventually use the github code owners feature so that we'll get you know Two reviewers on that extension moving forward and it doesn't have to be senior maintainers You know, we would kind of relax that component of it And the idea is then that we can Largely just push through reviews to extensions directly to people that quote own that extension And then an existing maintainer can just rubber stamp, you know Those reviews and basically merge them or it's acceptable if a maintainer is one of those reviewers and is actually doing work That's that's fine. Also, so but the kind of the fundamental Goal here is to incentivize people who would like to get extensions in the repo And there's a growing number of companies that would like to do that to actually be Maintainers if they would like to get extensions in the repo. So it's kind of a pay to play if you will Alyssa had the legitimate concern that that bar might be too high and like I don't I don't really have a good answer here So in terms of, you know, whether we should say, okay Like we'll do the reviews and shepherd it through if you agree to do these five issues for us or something like that And that's a totally reasonable proposal. I I have a feeling that we're just gonna have to see how it how it goes But anyway, I just wanted to kind of open it up for discussion and just see if anyone had any thoughts or concerns or Wants to do something different. You're on mute. Hi Matt. Oh Hi, I just unmuted myself. This is Stefan Zurcher I was wondering if you had any thoughts on what might happen in the future if you know You get a couple maintainers for an extension and then they You know move on in their careers and aren't Yeah, I'm interested or don't have the time to continue to do that work for an extension Yeah, so I I put I put a small section in the in the dock here about that and like again There's no there's no perfect answer here My my assumption is that once an extension is in the repo It's everyone's responsibility to do basic maintenance. So basically like if there's an API refactor Like it's people's responsibility to go through and fix the extensions as part of that refactor That's kind of the benefit of the quote monorepo approach in this case the the kind of the way that I wrote the proposal though is that Obviously, it's acceptable that maintainers of extensions move on If there's major known issues in an extension and we can't find replacement maintainers Like if there's no one that wants to step up to basically maintain it We would have a vote of the maintainers and then we would basically delete it Yeah, so Do like what's the policy in the Linux kernel? As far as I can tell the Linux kernel is like total chaos I mean, it's like there there there are drivers that like have Literally one person that ever wrote the code and no one ever reviewed it So the the the bar as far as I can tell and my information might be out of date here so if there's people on the call that that kind of understand the process better than I please speak up but My impression is that the Linux kernel has a lower bar And I think part of that is that they don't do the same type of CI that we actually do like they don't They don't build the whole code and actually test it like they build, you know The one configuration that works or a couple configurations and do CI and like a lot of the code There's code. I believe in the Linux kernel tree that doesn't even built so like it's just That's just kind of there's bit right there So one community that actually may be slightly instructive here and I've not put my head over a couple of years now but at one point I was a maintainer or On wire shark back when it was ethereal and in that the baseline was your shit had to work It which ethereal is just basically one giant shambling mound of plugins effectively, right? It's all extensions that I sector And and the sort of rule of thumb was if a major API change was being made which at one point happened frequently Whoever was making that change was responsible for getting it into all the places in the code base But then beyond that, you know If if something was truly legitimately broken and nobody was interested in fixing it exactly what you just described it went away Yeah, you're sort of in the critical path for stuff that's been done this way for decades Okay the build issues which I think are solvable And the quality issues and that's kind of like, you know, where Why we actually care about the code review bandwidth here, right? I mean it feels just doesn't build see I could do the job of dealing with scalability as we get more Maintainer as we get more extensions and we wouldn't need to scale the maintainers, but I feel Like we actually want to maintain the same quality bar as the core code. Yeah. Yeah, I mean it's again it's like so just being honest and like Realistic about it quality comes from production use like there's no there's no substitution for production use and It's hard to track the production use of all of the extensions like very clearly some of them have a lot more production use than others. So I Guess the other thing that came to mind And this is something that we don't have to do initially is that although I still want to do a CI of all code Now that we have a very nice extensible build system One thing that did occur to me is that we could we could publish two separate Docker images one of them is a Release build which is basically Envoy everything, right? Like you get all extensions that are in the repo and then one of them is like Envoy Bless like call it what you will but like it's the subset of extensions that we as maintainers feel have very good production coverage So like if if users are looking for like the quote blessed set of extensions You know that would be a place to start and then the people want to use the giant bucket They can use the the other Docker image effectively It doesn't even need to be done with documents It's I mean this is this gets back and now we're getting drifting a bit off topic But it's the original idea that we would have the effects of the equivalent of config files Builds and we would have full minimal and yeah Which would possibly put that or experimental. No, of course. Yeah, and like we can easily do that I was just making the point that most people don't know how to build Envoy and they don't want to do it Right, so it's like just if if we're gonna do a minimal and a and a full like I see no reason Not to just like do a CI run for both of those and publish to Docker images Like it's just it's just kind of a nice convenience for people. I think Yeah, so My main thought and I think this is already covered is that if Some extension code has less scrutiny than others if that is resident, you know, if that isn't built Then it can't really do any harm So if the Docker images and the kind of prescribed way of building the minimal subset Doesn't even pull in that stuff. Yeah Then it does make sense to have like a lower bar and make it easier for people to get their stuff and We also we also had this idea that we would have a separate repository Which is just open access anyone could just dump whatever they wanted there I guess as long as maybe a pile but that was the only bar. Yeah So so my my idea there, which is not part of this proposal is basically we would have an extension sandbox repo It would look just like envoy filter example. We would do exactly what we do today We would do CI on it. We would on every envoy master commit We would you know We would basically push the current sub module up to date and like the current maintainers won't track CI status on that repo Like if it's broken, it's broken like the the larger community will have to come through and basically fix it I I don't feel like I think that could be an interesting way to go I don't feel like there's enough demand yet to kind of justify setting that up But I feel like that's something that we can definitely track I guess my vote would be to start with some variant of this proposal And like let's just see how it goes and like where where the friction is and kind of like what people are complaining about And I think if we hit a situation where someone really wants an extension and no maintainers want it And the people don't want to be maintainers. They could maybe set up that Right. Yeah, right. Oh, or you know, I mean like there's even Intermediate solutions, there's like we have a documentation section where people link to their like repos which have their extensions in it or something like that Right. I mean, it's like there's lots of low friction ways I just feel like we can be nimble here and kind of like what we're doing today is not working So like let's try something different and then if that doesn't work, we can we can try something else. I guess Can you clarify what what we mean by an extension as well? Like is everything now treated as an extension so the things that would make it to like core mono, right? So that was the I spent like three weeks doing that giant repo reorganization Which was truly awful, but it's now paying off basically everything in source extensions So like there's a there's a very I think and in the in the root of the repo There's a file called repo layout MD That kind of lays this all out, but basically anything in the extension section of the repo is what we're talking about as an extension So like these are all of the static registration extension points and in the future will likely also support dynamic loadable modules in in these same places so with respect to the sandbox so just to relay the experience we've had with VPP so from the beginning we we did send set up a sandbox and So in some instances there, you know, and this is where two and a half years in There are some you know sandbox Implementations that people still play with and there are a lot of them that you know We originally had a 90 day or or or six month policy To automatically purge which we've never really done But it in some cases. It's been fine some cases. There's stuff. That's just bit rotted and left dead there There's still stuff that people use so I mean, I think it has some value You know as a place to just put stuff that that are At least at one point had been relevant to the mainline code Cool. Yeah, I'm not opposed to it I just don't think I don't want to do all the work set it up and like have all the policies if like no one's gonna end up using it So I think here the sort of suggestion of let's wait until we have that problem is probably the best one Let's wait until we actually actively have the problem of an extension that nobody wants to maintain And then we can talk about the right way to deal with it. Okay What one thing that I'm tracking with Alyssa and Harvey is that we we need to get someone from Istio to to Either be a maintainer or like do a bunch of work because they have they have quite a few extensions. So Yeah, okay, so that's something that I think the three of us can take offline and then hopefully we can report report back on that Okay, cool So if there's no major objections What I'm gonna do is I'm gonna kind of clean this up just a little more and then I'm gonna Do a PR to the repo in like the government section We're all all linked to this doc and then we'll kind of make it the quote official policy and we could just see see how it goes Okay Great Dave do you want to give us an update? sure Unfortunately, I was side-tracked quite a bit last week doing some VPP release management stuff So I have made some progress And so I hope to have a patch this week appear this week that I can Can publish that will let us identify the areas that I'm Running into issues, but for now, it's it's I'm still making forward progress. So Okay, what yeah one thing to point out is Brian Payne from Pinterest just did a PR to start the work of getting rid of FD from the buffer interface Okay, that that is part of what you'll need to do, which is very convenient that he started to do that You know I want to reach out to him over email or slack I can make that connection just because he had he had investigated a little more as to like what what was required to actually make That happen. Yep, but that's work that needs to get done. So if he's already done that investigation that might be useful Yeah, that would be great because yeah, there's some areas that I keep getting stuck mentally so Yeah, cool and and I've been focused not on you know, just on the generic Let's get rid of the FD stuff. I haven't been actually working on You know extension stuff that that might be specific to VPP. So Great cool Anyone else have anything that you would like to chat about On that note, I think they're I'm a third person working on some refactoring for the UDP stuff So what was kind of the outcome that we just mentioned that Brian had pushed up some changes or should follow that and put off of that? There's a PR that you can look at emerge like in the last day. It just it doesn't change the interface yet But we no longer call into LibEvent to actually do the read so the read has been lifted out And then there's just some more refactoring that needs to get done to basically get rid of the read and the write methods from from buffer Okay, is there like an epic type of issue that the tracks all these things We have github so Say Chris, what was the thing that people keep talking about that we can supposedly use that sucks less than what? You mean like you get up project boards I thought there was some other tool that people were using that that you told me about like project management tool for github There's waffle, but I know I Mentioned reviewable.io. That was just tracking your backlog of PRs review not actually Jira epic board style of what's waffle? another project board-esque type thing and Hello, ask and it's forget hub or no forget Um, so if people are into it, I'm I'm a big fan of project management So, um, I'm I'm happy to look into some solutions like I would love to have Some better way of like trapping it tracking epics with like sub issues Um, so if people aren't gonna flip out about it. I can investigate Hey, hey, Chris. What's your impression been of the github project boards? Like is that It's improved. Um, it probably worked for you. I think it depending what you want to do. So, okay All right, um, let let me go poke around a little bit and and and see because I kind of agree that if we could have It's like labels only go so far before it's kind of a pain So, um, let's see if we can do project boards for different projects and that that might be useful Sounds good to me Okay, and I I won't actually suggest that we set up Jira because I'm sure people would would freak out All right, anything else Okay, have a good week everyone. Bye Thanks. Have a good one