 All right, we are recording. Thank you much. Keyvert, I think Amy sent me a nice link with all the, an email with all the links to the projects. Yeah, so anyone got any comments or queries or questions about Keyvert? Personally, I thought it looked in very good shape. I think it's a good project. I would echo that. I think it's actually becoming more relevant as the platform matures as well, as far as, you know, modern modernization for migration to Kubernetes is a kind of a backfill. Yeah. And they're getting like really good metrics and adoption numbers and being used by quite a lot of providers. So hopefully that will help spread the maintain a burden across a few more organisations in the future. So, yeah, shall we do the same things we do in Sandbox Reviews and just use chat for kind of votes for accepting the Keyvert annual review? Do we want to address Chris's comment about it being very red hat? Is that something that we want to provide to the project going forward that we'd like to see a more diverse set of contributors? I mean, I think that's we I think we want to see that in every project. I don't know if that we did state that you could you can respond to it. I was just making a public comment based on the developer stats that it does seem a little bit red hat heavy. But for where it's at, it seems OK. And they pointed that out themselves. I mean, they said that the current owners are all red hat. And they did say later on that they think it's in a healthy growing status and they're working to imply a more diverse group of maintainers. So I think they're aware of that. All right. I put in the chat vote cube, but that's basically if we vote plus one, if you are happy with the annual review. The next one is Cader. I never know how to say it, Cader, Cader, whatever. Now, I think I said the same thing when they came into the CNTF. I think they're great. I think it's really useful. It's got loads of people using it. It doesn't really seem like it would have an independent life outside of Kubernetes. And I don't think that's any fault of the project. This is no in any way criticism project. But I think it relates to some of the conversations we have about like communicating about projects and. Like for an end user, they couldn't it wouldn't be meaningful to say, oh, yeah, use Cader unless they were using Kubernetes. And then I almost feel like we need some kind of. Project groupings, if you're using Kubernetes, here are some other projects that you might want to consider alongside that doesn't really have any bearing on their annual review, but it does have bearing on the fact that they want to apply for incubation. And I don't know whether there's no reason for those to be. You know, we could say, yeah, incubated projects, graduated projects can be part of a bigger family of projects or something that I'm just trying to explore ideas of ways of organising these large numbers of projects in a way that will be easier to navigate. So I just wonder if anybody's got any thoughts on that. Do we have any similar projects in incubation or sandbox similar category of the projects that we already have? So one that springs to my mind is from Atheist and Thanos. Um, so there will be more in your. Yeah, sorry, go ahead. Oh, no, no problem. I just want to understand your comment a little bit more deeply. So it almost sounds like you're expressing a concern that they only that they're only applicable to Kubernetes. And it feels to me like there's plenty of projects that are only applicable to Kubernetes in the CNS. So can you say a little bit more about that concern? I think this may apply to other projects as well, not just Kader. And I don't mean at all that this is in any way a negative reflection on Kader. I just mean that from. And from the perspective of thinking about how many graduated projects we should have and how we want to help people navigate the landscape. This particularly feels like an example of something that just doesn't have a life of its own. Like it can only exist as part of Kubernetes or kind of related to Kubernetes. And yet it's not part of the Kubernetes project, which is fine because Kubernetes is already huge and doesn't need to encompass everything. And not everyone has need for Kader. So I think it's fine that it could be separate. I just wonder whether it tells us something about a model where we could say. Almost like not every project has to be a top level project somehow. Just does that kind of make any kind of sense? Yeah, another background is I'm looking at the undercar. I'm sorry, I'm looking at the car in the sandbox project. I see there will be more similar project coming. For example, Tencent Game, they are talking with me, they want to donate a project which is a couple of workloads controllers. I mean, operators for their game, NG, which is quite specific to Kubernetes workloads. And another similar pattern is some other company try to donate there. I think it's a Chrome job, HPA, to see in the sandbox. And also see, for example, open cruise from Alibaba, it's basically like a state for workload management controller. And yeah, I think they share a similar pattern. If I understand correctly, I completely agree. I think open cruise was another example. And we actually had the conversation with the Kubernetes Steering Committee about open cruise and whether, you know, they have any interest in it being part of Kubernetes and they didn't, which is totally fair. But yeah. I mean, you have to remember the incubator was killed off. So we kind of act as the release valve for a lot of these projects. Essentially, what Sandbox is for a lot of folks. Yeah. So I think with my comment there, I've slightly derailed talking about Kader itself. But I guess I just wanted to flag up that idea of perhaps we should be thinking about this grouping or family or something for projects. And reading the Kader dot really made me think about it. And but aside from that, anyone got any comments or concerns about Kader? They seem to have a good community, a diverse community, which is very good. Yeah. Yeah. Yeah, personally, it's supportive to Kader because I saw they have a very good contribution from diverse community. A lot of people are contributing components and integrations to this project, which is a good sign for this project. And so I'm personally positive to this project. And they are proposing or they put at the end of their annual review that they are planning to propose to graduate. I think they mean planning to propose to graduate. But, yeah. So I know Tom had reached out to me and said, would I be interested in sponsoring the incubation? I was like, let me read the annual review first before I say it. Yeah. OK. All right. Shall we do votes for Kader unless anyone has any other points they want to make? Good. Good. Good. And the last one is service mesh interface, which anyone any comments or thoughts? I think it, yeah. Looks good, seems to have lots of momentum. And they've actually said they also plan to file for incubation soon. Users using it, I guess, is the kind of question I'd have. I guess, like, there are implementations, but like I users using those implementations in order to be able to switch providers or I mean, there's not much comment about how how end users are using this or how they say it, I guess. I mean, obviously, incubation, we would ask those questions directly, but there's nothing about that here, which is. Yeah, there is some comment about. Yeah, while some details for incubation appear to be focused on suitable metrics for source code, not necessarily specifications. So I think they're also a bit aware that they're going to have to, you know, it's harder to look at adoption metrics for a spec, but. Well, yeah, except that you'd expect users to be programming against the standard against the spec to some extent. I mean, it's I think users or actual implementations of the spec. So things like, you know, all the service measures would have adherence to the spec versus mostly users programming against it. Users just going to go directly install a Linkerd or an Istio, right? But if you use Linkerd and then you just. I mean, it's only a value if you if if you actually are using just the SMI endpoints or something. Otherwise, you're just Linkerd. So you've got the user has to actually view that the SMI conformance is giving them some kind of value. Yeah, SIG network, we're doing something about. Well, maybe it was more about performance and conformance. But it would be really it would be quite nice if SMI turned into a thing that, you know, we could say service measures are conformant to or not. There is some work being done in the community around that. I think Lee from SIG network has a kind of effort around SMI conformance, but it's still like super early days from my perspective. Yeah, we've got this great list of ecosystem service measures. And I suppose that doesn't actually answer the question of can you interchangeably swap one for another because they support SMI? Yeah, or even like, is there any real value to SMI? Like the fact that you can swap them, do people swap them or do they get any value? Whereas there's just like a tax all service measures pay and then no end user gets any value out of that. Maybe that's a question for incubation, though, rather than and if they're going to go for incubation, we can. Yeah, I think that's probably the best place to ask it because that's that is one of the big incubation questions. But it would be nice if they had addressed it a little bit as well. They have a line about updating the adapters for ongoing compatibility as a goal. So maybe maybe it would be nice to like document how much of the functionality of the actual implementation is covered by the SMI and how much it's outside. I don't know, just to have an idea, generally. Yes, I mean, certainly in terms of support from. You know, lots of different companies, there seems like there's good momentum here. So it reminds me of like maybe CSI in the early days where things are a little bit messy still. I still think they have some time to kind of build enough momentum to get somewhere useful. All right. We do votes for SMI. Well, that annual review. OK, annual reviews are done. Hooray. So what other topics I think we've got?