 Okay, all right, we are recording. Welcome, welcome everyone. This is our sandbox application review. We are hoping to clear as many of the projects out of the queue as possible today. We have with us some of our tag chairs on the call to observe and potentially provide any insights that the UC members may not have gotten the chance to go over yet. We first have two returning sandbox projects, and then 12 additional new applications. We're going to try to get through as many as we can. All right, let's get started with X line. This is a returning storage project. Nikita, can you give us a brief update on this one? Sure. So as a refresher, so X line is a geo distributed key value store for meta data management, so which is based on a protocol called good. So they mentioned that when existing distributed key value stores are deployed across data centers, the latency between nodes, maybe 10s or hundreds of milliseconds at which point the draft protocol will start to become a performance bottleneck. So the code protocol was designed to solve this problem. Now coming back to the concerns that we had raised earlier, so tax storage recommendation is that we consider them for sandbox, especially given that they offer a novel approach to existing functional areas. There was also concern raised earlier around the lack of contributors or maintainers, especially given the health of the CD project. Tax storage also acknowledged this concern being real and but it's also like true across the board for even graduated projects in certain areas within a graduated project. And we also had a question around whether they the project would need any legal or IP assistance and they clarified that they would not be needing any. So with all those discussion points, I am personally plus one for X line coming in the sandbox, but I also want to know what others think about it. So we've had a lot of previous discussion on X line we did get an update to all the questions as my key to recap for us does any other. Do we have any other comments questions or concerns for the project before moving on to the next one. Just a quick comment from tax storage we've reviewed the product the project and it does seem genuinely innovative. It is a fairly early stage so you know sandbox is the right place for it, but I think the level of innovation is interesting and something we want to track. Awesome. Thanks so much. Yeah, I thought they answered all the questions very well and address all the concerns I heard so I'm positive about it. Josh had posted a question in slot in the chat around the repos that would be in scope for the for acceptance into the CNCF, because there is a lot of other items within Dayton Lord. I believe it's just the X line, but we can certainly follow up out of band on this issue just to clarify which ones are within that. I mean my question is, is it excellent and curve which their materialists were kind of imply, or is it just well X line also has a couple of other named X line thing. I just couldn't find anything in their application specifically the three plus they're talking about. We should probably be a bit clearer on the phone because I think when we when we mean, when we say org, we actually mean are you denoting a whole log, I think is what we meant to mean. And if so what is it versus the repo maybe we just need to have a bit of their wording on that because it's sometimes people have an org but they don't mean to donate all of it but they still have an org. Yeah, and this one pretty clearly there they do not mean to donate the entire work because they have a lot of other stuff in there. Yep. All right, so we've got an action to update our sandbox form. And I think what we'll do is we'll follow up with this project through a comment after this meeting just to get clarification on which, which repositories are included within it. Is there a to see member that is willing to take on that action, or potentially a tag chair. Nikita, you'll follow up. Thank you. All right. Next up eraser. This is a returning project Ricardo had reached out to them last time to get some verification or clarification on preventing vulnerable workflows from deployment with this project, as well as some of the similar runtime security projects within the type of landscape. Ricardo did you want to provide any additional color or commentary on the updates. I think the updates are clear. So they don't see too much overlap with the tools that do scanning. We're at the registry level, they do some sort of some level of overlap with runtime security tools like Falco and similar. But they highlight this is mostly focused on the image cleanup of the caches on the on the nodes. So there is value on it and also because this area is kind of still evolving. I see it as a potential candidate for sandbox there was an additional question from Josh regarding integration and why this isn't in Kubernetes itself. Which it replied. Also saying that this is not specific to Kubernetes, but can also be applied in other environments. And potentially this could be taken by a working group later also in Kubernetes. Okay. Thanks Ricardo. Anyone else have any further questions discussion points for this project. Alright, so next up is why my store, why my store is a local storage solution for cloud native stateful workloads with high availability capabilities and full life cycle management of the local disks on the Kubernetes worker nodes. Is there anyone that wants to kick off the discussion around this project. Alex. In the absence of comments I can give a quick update there so wanting store presented to the tank. It is a local management of pvcs and local disks. Whilst there are some similar projects like Karina that's already in sandbox that has a similar sort of function. Just some unique things about one store around being able to migrate data between nodes and and providing additional ha and migration capability which which is quite different to to the to the other systems and it's based on the operating system and and not additional sort of third party products that need to be installed in the system so it's kind of very easy to to adopt. So I think it could be quite interesting there are a lot of stateful workloads that depend on that local storage and this could be a good way of doing it. Appreciate it. Any other questions or comments from to you see members any observations they had. Okay, I will move on to the next one. API improvement proposals or a IP IP is focused design documents for flexible API development. There are some core aps to specify patterns and practices for cloudy PIs and have a good developer experience around that with robust secure and scalable design to support a variety of client integration paradigms and provide evolutionary flexibility. This project appears to be one of the more non traditional projects in the sense of how we view sandbox applications. So I'm curious how some of how we've reviewed this, what do other TOC members think I personally do not see this as a project I see it as a collection of best practices that could be highly valuable for some of our software engineers within the ecosystem or even some of our adopters to reference but I don't necessarily see it as a project, moving on to incubation or even graduation. What do others think. I have a vote I poked into this because I was curious to them submitting it, you know and seeing hey do they actually have, you know, API management generators or other stuff that's in there and there actually isn't any code in any of the repose. You know, you could you could potentially have code around this concept, at which point it might be worth looking at still whether or not it's relevant to cloud native but there isn't any. You know, publishing a white paper or something like that. It's a better fit than the product. Sorry, they, they, they, they mentioned the linter as Kate, like on, which is not in that or as well on the perverse old is it. So it's a little that maybe code but they're not contributing they're not proposing to contribute it. So, I think they are. I think that's, well, okay, it's not clear. I kind of assume they were but. So I'm hearing a lot of life clarity and what actually is being contributed, even if it did include it linter. So let's just go down that path. Does this still feel like a cloud native project. Matt you're off mute. Do you have any thoughts. Well it doesn't seem like a cloud native project to me. That's the, that's part of it but also how does this project to incubating and go to graduation and I think about that because I was working on artifact and I was looking at okay, what do we consider to be an adopter, and then how do you track what the adopters are. So if a project does follow this, how do you track them as an adopter and even know so that way you can point it out to us. How does something like that work. And I think it's going to be more difficult to track than other things where you can look at their code, and you can look at what they've done and what's been shipped and what's, you know, you're they're going to have to explicitly document it. Which is going to make it a little bit more difficult in some cases, but it also doesn't fit the cloud native definition, because I could take things that are definitely not cloud native and probably apply the same things to it. But how does it fit here is the question and you know we always need to look at how do they go towards graduation, and that's where I'm starting to see, like I don't see that clear path for graduation, and I may be missing something but I don't see it. And I don't see it fitting in this being cloud native. That's just what I, somebody can probably argue me into those, but those are my outstanding questions right now. Nikita and then Justin. I think I have a hand raised up for a while so like I wanted to make that point as well like, I don't see this as cloud native at all I have played around with a ideas before. And I think they're really useful project, we could probably consider them if other CNCF project start using it and see value in it. So maybe we put it in like the data practices or that was suggested. But I don't think we should even be considering it right now that given that other CNCF projects actually adopting it in the first place. Justin. Yeah, I think I think what's unclear to me is also how how to adopt it and if there are potential people who do want to adopt it because the it's a it's a set of, it's a set of Google standards, which are not being donated, but which they the instructions recommend you fork and modify but I just, I don't understand what the how the community would use something like this effectively. And I think it would be, it would be good to see more of how it can be used by someone else and how the, the structure of the repo and the organization works for other people to use it or collaborate on it or whatever first potentially because it's very unclear to me how anyone else would would use it now, which is kind of related to the point about. Well, I think there could be routes but it might, but then it's not clear that there are you can fork, you can fork Google guidelines and modify them as for your own is a is a thing that will build a community around a project. I agree. So it sounds like we've got enough information to move forward with a decision so let's move on to the next one. Yeah, to come to a vote or yes, okay, thank you. Keep clipper. It's a lightweight friendly reliable and stable platform that provides a friendly GUI API and CLI for Kubernetes cluster lifecycle management. They're specifically looking for vendor neutrality. I think that this could do well. Personally, however, they could potentially go to tag security the environmental sustainability there are comments within their repository that talk about minimal utilization and really focus on the minimum requirements for deployment so there there could be opportunities to further reduce that. I wanted to check in with the other to see members and other folks on the call. You all have any comments observations about cube paper. I had a quick one. I see this project as fitting but there was a comment about presenting first attack runtime. Did they do it in time or doesn't look like it. Did they present to tag runtime first before making a decision. I don't think so it was just if we had more information from the tag already. This was actually. I'm sorry, Nikita. I was just saying that they're presenting in tag runtime this cluster. Okay. Any other comments. Do we think this one's a good one to bring to a vote. I think yes. Alright, next up and cube stellar. Cube stellar is a multi cluster configuration management for edge multi cloud and hybrid cloud they've already presented to tag runtime. Any questions observations comments. Josh, are you asking for cube stellar on being asking about the previous one. That would be my one concern about the previous one and unfortunately I didn't get to that one before this meeting so they could answer. I'm not clear from the documentation repositories, whether their management interface is cloud agnostic or whether it is specific to their cloud. Okay, because it was specific to their cloud then we need to ask them about what plans they had to make a cloud agnostic. Yep. Make sense. Thank you for the comment. And the question. I kind of looked at cube stellar. Are there any considerations, additional observations that you have associated with the project. I'm a little bit on the fence about this one. I think that there is value in having this added. However, I'm not an expert in this particular area. So I'm curious what other folks feel from runtime or some of the other tags. Kathy, you came off mute. Oh, hi. I think so this, this party and those, you know, some age, I think it spans a broad functionalities. So there's a party for cool age. And also it mentions, you know, the multiple clusters, right. So there's the other party that handles, you know, the management of clusters. I'm just thinking if they can clarify what is the difference or differentiation. You're looking for the differentiation between multi cluster and what was the other item. Cool age, the age class. Okay, we have a sense of a hazard project host a party called cool age. Okay. So better differentiation between their existing project and this one correct. Yeah. Okay, I think that's fair. How do others feel. Did we end us sir. Okay, so it does seem really early for this project. There's been a couple of releases. There doesn't seem to be a lot of adoption. Just from a quick view. So maybe not yet, but possibly in the future. Yeah. Ricardo. I was just going to say the same thing also because they're about to do some sort of reorganization of their repos. So maybe, maybe waiting until they're done with that and then reevaluate. You know, and go ahead. I was just going to add to this that, you know, their reason for why the CNCF. It doesn't really link back to any of the reasons we do sandbox projects. They're like, they could run this just find outside of the CNCF. And I understand, you know, it's born from the principles of the CNCF, but a lot of things are they don't need to be in the CNCF. So why the CNCF is still one of those questions I'm left wondering, is there a benefit to being in it for the CNCF or the project, because there's a lot of great projects that are part of the CNCF. So why sandbox. It sounds like re application after the upcoming reorg changes for the repo as well as some outstanding questions on the project. Is there a to see member that's willing to take that on and comment on the issue for them. I can't. Thank you, Aaron. Thanks, Kathy. Any other discussion on cube stellar and Amy for the record for cube clipper. We have an outstanding needs information for that project to get better distinguishments on bare metal. Sorry, not bare metal cloud cloud service offerings, whether or not it works across different cloud providers or their own platform. Okay, so clarification needed not coming up for a vote. Yep. And I can take that one on. All right, let's move on to spider pool. spider pool is an IP address management CNI plugin for Kubernetes for managing static IP addresses and underline networks. Is there anyone that one sticking off the discussion for this one. I'm wondering this is like a CNI plugin for Kubernetes right isn't this part of the communities. No, the network plugins are all their own projects. Okay. I can see this under the CNI project. I guess, but that wouldn't be under that wouldn't be under the CNCF. And those companies have already had quite some CNI plugins. Does CNC host those plugin. As part of it. I'm not sure any of them are CNC projects actually. I can't think of any offhand. Maybe I'm wrong. I think this project could do well from a from an adoption perspective. The question, generally speaking, it could probably do well from an adoption perspective because there are a lot of existing enterprise organizations that are either on their journey just starting out or halfway through this transition to cloud native. There are a lot of their existing problems with their network management. Using their existing architectures firewalls all pretty much anything that they already have in place and just allowing that onboarding to happen a little bit smoother for them. But whether or not it's cloud native I think is a good question to ask. And I have a question for you all is whether or not you think that this needs to move to a vote or if there's additional information that we need to receive back from the project that would influence a decision. I'm not to see but just a quick comment was this does seem a bit niche but it does have uses in more traditional infrastructures, but it definitely it would definitely help in allowing some of those more traditional infrastructures to kind of become more cloud native. So there is that. Do we think that we can see this actually reaching incubation level. We don't have any CNI projects other than CNI itself in CNCF, which is kind of weird because some of them are quite big projects but actually well, you know, I don't know. Yeah, that's the thing I think we ended up with service measures not CNI is in the end as a category, which is a kind of abstraction there above if you want to look at it like that. So here's a different question then around spider pool, whether or not, because we don't have any CNI projects within the ecosystem. Are we missing a potential adopter pool, because of that, and would this project fill that gap. So I see, yeah we have CNI as a CNS and project, and they are quite some CNI plugins. So I wonder I'm thinking you know if we allow this to be how about the other projects. The other part you may also start to apply. Then we're going to have quite some CNI plugin projects. How we should deal with that. Sorry, I meant to be muted. I mean I am aware that at least one of the CNI projects was thinking of applying previously. I'm not aware of any other CNI projects but I do know that the CNI, the container networking interface project in GitHub underneath container networking describes itself as a CNCF project, which I think is true. So, yeah, sorry that the CNI project itself is CNCF but not any of the individual CNI implementations. Yeah, so isn't that just a historical accident of most of the CNI plugins being commercial offerings. It's probably true, yeah. No, there's, in the landscape we live wave and flannel and Calico and all those open source. Right, they're open source but most of those are also commercial offerings that have decided not to put themselves under CNCF governance. Well we've we've we've was the one I'm aware that they were interested in contributing to CNCF a while back. So this doesn't get with you. I'll come back to this though when I look at why the CNCF right. The first thing is it increases awareness. But the reality is a CNCF sandbox projects don't get increased awareness just from being a sandbox project they don't get the marketing and other things. Some people may stumble upon them as a sandbox projects but by and large we observe that people don't get improved awareness just by becoming a CNCF sandbox project. They do something in their own right to be interesting. And then with guidance of the CNCF right, they can adhere to requirements and set directions, but the CNCF in itself isn't going to set guidance for spider pool they're independently governed. And so there isn't somebody here who's now going to set requirements for them. They may be able to go towards you know, some tags and some other places to get guidance from there but they can actually do that anyway. So when I look at what is a sandbox projects give them and why are they looking for the CNCF. I wonder if there is an expectation mismatch that they're looking for things from the CNCF that they aren't actually going to get by joining the CNCF. Ricardo. So I was just gonna reinforce the previous comment that this might be an issue but there's a need from some deployment some end users to have some solution like this. And answering Emily, I think I see this project, applying for incubation and and moving forward. So, I don't think that's that's a stopper. I think we're going to make it Duffy and then we're going to make a decision. That's going to get your question about like whether this, like, are we missing a gap and would this fill it I think this is interesting because it is, you would deploy this in addition to another CNI. I don't see this as a complete CNI in itself. This is like extending features for particular applications in your in your use case. This is where I think that you skate. I think it's an interesting project because it tries to solve some problems that perhaps other she and I still specifically go after, but I don't know that it would like completely be a replacement. I don't know that it would live on its own as a, as its own CNI. I see it as an indirect project as well. Okay, so the question that I have is it was proposed that this go to tag network. My question for you all is, if we send them back to tag network to do a presentation and discussion. What information are we hoping to get back out of that activity that would inform a decision for us. I think we would want a specific recommendation whether or not it is appropriate to be included from tag network. Given that they are the SMEs in the space and understand the ecosystem. I think it's important to rely on their attention on that. Yep, I agree. So, which do you see member wants to champion or provide the comment back to spider pool to receive to go and present to tag network and for tag network to come back with a recommendation on for its inclusion within the landscape. I think to that, so just, I mean, to the tax network, right for recommendation. Yep. Yep. Thank you, Kathy. Okay. Next step is Kpt. It's a Patrick centric package centric tool chain that enables was even configuration authoring automation and delivery experience which simplifies managing Kubernetes platforms and Karen driven infrastructure at scale through manipulation of declarative configuration as the data. Does anyone have any discussion or observations to kick this off. Josh, you came off mute. The first thing with this is, I mean, this is a project that came from inside Google. So hopefully, somebody here should actually know more about it. My main concern about it would be ongoing maintenance, because the current maintainers are people who already have like 15 different responsibilities and cloud native. It's a good call out. I don't disagree, but we should not take that percent. What, what would they hope to get out of sandbox and how is this. Again, some of these projects today are extending the ecosystem not necessarily integral to it. So, perhaps this is the direction we're heading for the CNC at this is more these kind of ancillary projects that would go to what tag this would go to to be honest. Yeah, I had trouble with that as well. Isn't it a tag management, which is something we've discussed before. Is this app delivery. That's all around apps. That was the closest one that I could come up with. Okay. So, let me ask a different question associated with the project. The problem that it's trying to solve, which it's not really clear base. I've looked at the repository. It's more a different opinionated take than actually doing something brand new, highly innovative experimental again it's an extension. Is this a project that we can see reaching incubation or even graduation levels of adoption. At this current state, I can't imagine it reaching graduation to be honest, but I think that this. Sorry. No, go ahead, Justin. This problem space is real and there's been a, you know, a lot of exploration in it, which is one of the purposes sandbox. You know, I think that there's a, it does like managing configuration at scale for something that's a real problem. And I would hope that one day we have a solution that reaches like getting incubation or graduation. I don't know if it would necessarily be theirs but you know I think that it's a real problem. Yeah, and I do see a path to graduation but it's a difficult one right. So when you look at how they would have to look at adopters. You have to have other projects mostly take and integrate their work, whether it's their SDKs or rely on their CLI things like that, in order to build upon what they have. So an adopter might be something like an SDK or their CLI as part of a VS code extension. And I think it's going to be difficult for them to get a bunch of adopters there in order to meet the adopter requirements along the way. But I do think it's possible when you look at it this way just looking at adoption from that non traditional mindset which we're starting to see. So I do see something there. And their reason for it is an interesting one, right, they would like to use the CNCF CLI because it's widely accepted and adopted, and it's different than using the Google CLI which is what I'm sure it's under today. It does allow for a wider contribution pool. I think that is their reason they call it here which I think is an interesting and useful reason. Okay. So it sounds like we have some considerations for its potential to reach graduation but there's a lot of our blocks associated with it. This is again an extension of existing capabilities that are within the landscape. Is this something that we feel given how, given the age of the project that we need to have them come back after a period of time a little bit more robustness maturity, more clarification in the use cases in the problem space that they're working towards potentially doing a presentation and app delivery or do we have enough information to make a decision on the project today, given the information that's presented here within the application. I think we have enough I would say I don't think that you know it has been around for a while it's So I think yeah I think we can make a decision. Okay. Yeah so so for this, this project. This is used in another open source party called Matthew, and it is that that your party is used for class committees class management. So this for, I mean better configuration. It's quite it's I will say in terms of the, I mean, the technology itself is quite it's kind of it's not like, you know, very primitive. It's mature they have, you know, implementation on that. Thanks Kathy. So this one will move to a boat. Next up is easegrass it's a cloud native track traffic orchestration system with a lot of different considerations and its design. One of the things that I do want to call out for to see members and other folks on the call is that the application is a little light on some of the content that we traditionally look for. As well as it's a named product of a company I believe it's a company called mega ease. And it's by the same name. So they specifically call out easegrass on their product page. Does anyone have any additional comments or observations associated with the project. Something that we feel can move to incubation or graduation. We haven't had a lot of network projects come in recently we've seen a lot more runtime a lot of app delivery as of late and more storage significantly more storage recently. So we might be helpful for them to present a dog network and also add more information to the GitHub issue before we can make a decision on those were my thoughts as well. We may also want to make it clear to them that if they donate the project, they're donating the name. They can't have a product with the same name, you know, a more advanced version. There can't be open core or any of that around it. We may want to clearly communicate that to them because I can imagine they just check the IP checkbox and didn't really know the implications of what it did to their business, which happens sometimes. Do we have a TOC member that will take on the action to comment on the issue for clarification of project separation from the product point them to the IP information that we have around joining the foundation as well as requesting them to present to tag network. I can do that. Thank you so much Matt. All right. Terracube. Terracube is an open source collaboration platform for running remote infrastructure as code operations using Terraform to replace closed source tools like Terraform Enterprise Scalar and ENVO. Anyone want to kick off the discussion on this one? I would like to just say that I'm excited to see that there is a project that has taken authentication first and done OIDC integration. So I thought that was pretty neat. We haven't seen that very often with some of our sandbox applications. Are you familiar with Terraform Enterprise because a lot of their application is centers around comparing them with Terraform, which is not a tool I'd ever heard of before this application. I'm not familiar with the Enterprise edition of Terraform and I have not used Terraform personally. How about other TOC members, any experience? We use Terraform quite a lot, but not the Enterprise version of it. Aaron? Yeah, same. I've used it, but not the Enterprise version. So, I would have to do a little more research to understand the differentiation that they describe here. I'm also wondering if that is just a gap. You know, like, how do we know that, you know, the features in the non Enterprise version won't eventually be merged, and then this kind of becomes irrelevant. I guess it's just kind of interesting, I guess, to try to create an open source version of something that's Enterprise, not knowing whether or not because Terraform does have two different versions. It would probably be in their best interest just to close that gap. And then what would happen with this project? That was my concern. I would also be curious about like any IP, perhaps. Yeah. Also, my other concern is, if we are going to take on a project that is essentially a feature clone of a Hashicourt project, it's not something to necessarily do casually. Yeah. Go ahead. Yeah, I was going to say like it looks like they also have very low contributor diversity would just do contributors making most of the comments. All right. So, do we have enough information on this application to move it to a vote, or do we need to return back to the submitters with request for additional information and so what are we looking for? Their long term strategy should Terraform wish to close that gap? Justin? I mean, I kind of wonder about kind of engagement for, they seem to be trying to build a product that is difficult to manage an open source, what is effectively an open source? I don't, as a CNCF project, because it's very vertically integrated. So I don't understand quite what the contribution model and contributor model is for things like that. Josh also brings up a point of whether or not we would consider it to be cloud native. Is there enough information to move this to a vote? See some head nods. Right, Amy. Next up, I hope I am pronouncing this one correctly. My Crocs? Probably not. The Kubernetes native multi product call open source enterprise testing and mocking API solution. Who would like to take off the discussion for this one? I think this one is interesting because it pulls mocks and testing together within the same project. Usually, from my understanding, those are traditionally separate projects or separate capabilities for enterprise adoption. Do we think that this is cloud native enough given our previous AIP discussion? See lots of thinking faces. Personally, I don't see the cloud native connect and I think it's similar reasons to the API one. Okay. Others. Do we see it reaching incubation or graduation? This one, the name is part of the name is same as a company name. My Crocs. Good call out Kathy. Yeah, contact emails. It's not clear to me as a company. It says community driver. It's not clear to me if there is a company or not. It's primarily a red hat or develop project. It's what we use to test a lot of our cloud native stuff. So, with the additional information, go ahead, Nikita. I just noticed like it says that lead for tag app delivery is one of the project champions. Should we ask that app delivery for more information and why they think this is a good fit for a sandbox for making a decision. I think that's a good call out. How do others feel. Okay, so we're going to ask my crocs to go present to tag app delivery so that the tag can make a recommendation back to us for a decision. It looks like they have presented to tag delivery after delivery. It's just the question is really can tag up delivery summarize why they think this project should be put in unless I've missed that comment. Well, I think we have that comment on the application itself. We do have a letter of support as a comment. Here is the issue from tag app delivery. So perhaps what we'll do is we'll reach out to the tag app delivery and get their feel for it. And then we can make a decision based off of their feedback. Does that sound good for everyone. Would one of the TOC liaisons for app delivery take this on to proxy that information and request. Yeah, I can do that. Thanks Justin. Alright, next up. Kate's GPT. Kate's GPT is Kubernetes cluster analysis augmented by artificial intelligence. And effectively, my understanding of the project is one it is extremely early AI is a growing interest space by a lot of projects and this is the first sandbox application that's looking to take advantage of those capabilities. It does talk about whether or not you're leveraging hosted or bring your own, which is nice for enterprises that need to have that sense of confidence that their information isn't leaving their environment. So how do the TOC members feel about this and our tank chairs. What are you all feeling about this particular project of seeing a few demos of this because because I happen to know Alex Jones. And it actually is it like it looks pretty clever you can kind of point to that the Kubernetes cluster and kind of get it to suggest what's going wrong when there is an issue. It's, it's interesting. And certainly, but like I like you mentioned it's obviously early days, but it does seem to be getting quite a healthy community, at least, you know, if the Twitter feed is anything to go by. Yep. Go ahead, Justin. Yeah, just seems really early. I mean we've we've we normally turned on projects that are only a few weeks old. And just on the basis that we can't see what direction they're going to go in yet and what kind of interest there's going to be and so I would just wait. Probably about what, let's say a year, six months. I mean, it's a fast moving field. So maybe six months, you know, I mean, I, you know, I think that. But, um, yeah, um, who knows, but yeah, some period of time like that. Yeah, I don't think we'll move this one to a vote. I think it is still very early. I there's a lot of really nice things that they're considering. Um, but probably recommending they reapply in about six months and we'll see where they're at. Makes sense. Okay. Is there a TUC member that's willing to take that on to let the project know or Amy? Okay, Ricardo. Thank you. Yeah. All right. Um, next up, we've got two minutes, which I don't think is going to be enough conversation for this project. But the project's name is Copacetic or Copa. It's a tool for patching security vulnerabilities and containers. This is also another very early project. I personally would like them to walk through their use cases with tag security because this changes a lot of the recommendations that have come out of the cloud native security community around patching and management of container images. Um, none of the documentation that I was able to go through kind of detailed where the where this would actually occur within the development lifecycle, as well as how many times an image could potentially be patched before it has to be rebuilt. There are some patches that are breaking changes, which if you're relying on this capability to close out an immediate vulnerability, you could also break your workloads. So there's there for me, there's a lot of outstanding questions in addition to the age of the project. What about others? Matt, I know you need to drop. I think what we'll do for this one is we'll hold off until the next time. I'm going to make a decision to you see members. Tag chairs. Feel free to comments on the issue for the liaisons for tag security. If you all could reach out to them and have them take a look that way. The next time we have a discussion on this project, we're well informed. Thanks everyone. Thank you. Thank you. Bye.