 Good morning. Hello. Greetings. Good day. Just give people a couple of minutes. Liz, we will likely have time for open floor today. We will likely have time to what so open floor is basically things so just kind of keep that in mind as far as the things that we currently have on the agenda are not likely to take the full hour. Okay. All right. Have we got 24 is actually pretty pretty much a good turnout for us these days. We got we got good representation from the TOC, Amy. We're getting there. Few more people rolling on in but we don't need quorum for this particular meeting today. So, I'm keeping an eye on it. Yeah, cool. Yeah. All right. Maybe we can get started. So, welcome everyone. Normal things. Normal behavior. And, yeah, so, as Amy mentioned, we'll probably have time for some open floor. But we thought we could have a look at the current set of projects that are applying for graduation and incubation and just try and get a read and discuss maybe some feedback for those projects. And I don't know if we have this on the slides but I'm sure a lot of people will be aware we've been talking about. And there is a PR I'm sure someone can find the PR for streamlining the graduation process such that we will have a quick discussion in the TOC just to sort of get a read on whether there are any. Well, either sponsors who are very keen to take that project through graduation or possibly if there are concerns that people have that basically say we, you know, we know we're going to struggle to vote in favor of graduation, because that's what concern XYZ. So that proposal is out there. We haven't had a vote on it yet, but there's no reason why we couldn't start having those kind of discussions. You know, now anyway, the process is about kind of formalizing something that we believe we should be doing anyway. Amy has posted that PR. Thank you Amy. Right, so I guess the projects that we have on deck for graduation. I think that's has been there for a long time. GRPC has been there for a while Falco has been there for a while. And not so long actually Falcos are more recent application. And we could probably just have a discussion about the status of those projects and see whether or not we have a TSE member forthcoming who wants to sponsor them, or whether we have any particular feedback for those projects at this stage. And I think you know it's useful to get input from the wider TSE community as well. But for both incubation and graduation we do need a sponsor to step forward if it's going to, if the process is going to go ahead so if there is an absence of TSE sponsor that basically said the project is not going to get through that next stage. So it would be helpful if we can articulate feedback to the projects about, you know, why people are not feeling confident to step forward. Does that make sense. Any questions or comments about that right now. Okay, do we are we also soliciting at all the tags prior to that. I think if there is. Yeah, I think the way that we described it in that PR it doesn't affect what we would do with tags at all this is supposed to be more of a shortcut process to say, you know, if there's some if the TSE. If there's someone who's really keen to sponsor a project, they can step forward earlier in the process and make themselves known earlier. And equally if there are people who have serious reservations we can make that known earlier in the process those reservations might turn out to be unfounded or wrong. But that could be input into what the, what the, what we asked the tags to look into, or, you know, if we, if we were to say, you know, particular project we don't believe is ready for graduation, that project would be able to come back quickly and say actually we'd like to do this because we think you're wrong for, for whatever reasons. That seems, you know, I think that's better than our current limbo situation but I don't think it actually changes. It's more about forcing us to have a conversation earlier, rather than changing the thing about how the tags involvement fits into the sort of. Yeah, I just wondered if the tags, if they had serious reservations like I don't know that every TOC we've had has fully represented the spectrum of technology that is the umbrella, right. Of the CNCF and so I just wondered if, if we also have that kind of that check with the tags if they had like, there are more boots on the ground understand maybe some of the interactions that they would be able to at that point. If they had serious, I guess I'm more in that if they had serious reservations they could also bring that up at that point. Definitely. Yeah. Yeah. Yeah. This, this early stage isn't supposed to be about like making a. Like, it's not about deciding whether things go into graduation or incubation it's more about deciding okay how are we going to go through this process are there some immediate things we want to get investigated or get dealt with. You know, if we have blocking issues that it might be better to tell the project, kind of straight away rather than saying yeah okay after six months of deliberation we've decided that this thing we already knew was going to be an issue. Right, I was just honestly thinking of like open EBS is an example, like, maybe that was well known in the, what would have been the six then at the tax now and not necessarily to the TOC, unless it been brought up through that process so I just wondered if we wanted to formalize that. You know, touch. Yeah, I mean I think they would still be able to bring up those concerns, you know it doesn't change the due diligence process in either case. Yeah, is that does that make sense to. Yep. Great, thank you. Any other questions or comments about the sort of general principle of that process change. All right. So, and this was admittedly quite a late breaking choice to discuss these on the agenda today so. I appreciate this is. We haven't had a lot of chance to go and research the projects but let's air the things that we know and and see where that takes us. So nets have been applying for graduation for a very long time, and we have historically had concerns about the, the kind of vendor independence of nets. The last we discussed it to my recollection that was a suggestion that perhaps going along the lines of an advisory group. I don't know if it like link ID have have put in place might be a way forward, but I don't know if that's actually made any progress in that direction. If anyone is aware or would like to comment. If we have anyone from. Hi, this is Ginger Collison. Nice team. That's Nadia hi. You know, we've been watching the changes in the TOC and. You know, the different criteria and changes to graduation requirements. We had discussed putting in a steering governing committee kind of thing and at the time we were doing this, and the level of effort it was going to take more discussions around the contributor strategy group and with the TOC was that that may or may not help us with graduation. So we kind of put a pause on it to see where the TOC was going to land and their graduation requirements before we move forward. So that's kind of where we are now. With link or D going through with graduation. So it's a little disappointing, frankly, just because we tried. And actually our diversity or contributorship or whatever, in my opinion, was greater than link or D's and it didn't seem, excuse me, that link or D went through the same rigorous due diligence that the Nats team had to go through so right now we're just kind of in a holding to see what we're going to do next and what is the best way forward for us. Right so. I guess we, you know, this doesn't have to be a kind of comparison of link or D and. And that's, you know, I don't want to kind of put them up head to head. We did. And I think they have. Actually, there's a lot in common between those two projects that there's, you know, there's a single company, and that for which many of the maintainers work, and I think actually William articulated very, very well that you know the challenge that if they have a really good approach to the project they want to hire that person and that's good for their business. So I think the fact that, you know, they came up with a steering committee model they work pretty hard to try and make sure that that steering steering committee had, you know, teeth within the governance process. They put the steering in committee in place a few months, you know, before they came back and reapplied for graduation so that we could see that it. Had. You know, it wasn't just a sort of passing fad that they had actually put that in place. So I think that could be a good model for a steering committee for other projects in a similar. In a similar situation like Max is in where there's, you know, for good reason, one company who are tending to hire the contributors and the maintainers for for that project. Okay, and a question also. So when we applied for graduation at that point the tags were not doing the due diligence documentation. To move forward would we have to go through like with tag network would we go through the due diligence with them all over again. So we should be able to reuse the incubation due diligence is starting point and the graduation due diligence is is a much kind of, you know, it should be a smaller process is really up to the TOC person who sponsors graduation to decide how much they want to delegate to the tag. Okay, and I don't even recall who our sponsor was at the time it might have been Alexis but he's no longer at the TOC so I assume we would have to get a new sponsor. Yes, that would be correct. Yeah, okay. Yeah. Thank you. I think if there were a because in many respects, you know, Max is a very mature project. I think if there were a good solution to the steering committee I wouldn't want to stand in the way of anybody else sponsoring it and this is very much predicated on there being some, you know, good stable steering committee solution in place but if that were in place I would sponsor it. Yeah, good to know. Thank you. Anyone else got any other comments or questions on that? Anyone else from the TSE got any opinions on Max's readiness for graduation. And so I would say the steering committee is a requirement for projects that don't have multiple organizations like as committers. I've talked a few times about how we want to document this and I think Josh is here and may have some additional things he might want to weigh in from the contributor strategy governance group. I think we always ended up in a situation where we didn't want to say a steering committee is like the solution we want because we would prefer projects to have contributors from multiple organizations. That's the better solution in many cases, but we have this situation where there are projects that have, you know, a very close relationship with one vendor. They, you know, have been there, they've been part of the CNCF for many years and we want to be able to support those projects in a way that doesn't, you know, that still provides the guarantees that we want to provide guarantee is a strong word but still de risks. You know that the project isn't quite that it isn't at risk of a vendor just kind of deciding to do things like feature hold back. I think that's one of the real risks. Yeah, the previous TOC decided that the two, the two reasons for the multi organization requirements the two things that the CNCF wanted to emphasize were number one that the project is open to contributions from people working for companies other than the original sponsoring vendor. And obviously, if you have a maintainer who works for a different company that that readily demonstrates that. And the second thing is that the project will survive something happening to the original vendor. Or has at least the possibility of surviving. Obviously, lots of projects have a problem in the second. So it's more of a matter of, you know, how risky is that particular risk. And, and, you know, when we discussed this multi organization requirement last year those those were the two things we're emphasizing. So I think on the new graduation short form there's a question specifically about the second. There is. Yeah. Yeah, it's something maybe dims or dims is sent his apologies but dims might remember the wording but yeah it's something like how will you ensure the longevity of your project in the event that the original founding company stops supporting it or something like that. Yeah, I mean my question was more about whether the TOC has thought about formalizing that type of process or maybe. Yeah, we didn't we didn't want to like write down a prescriptive. Like a lot of things in the CNCF and the TOC is sort of based on prior examples. So we didn't want to say a steering committee like this is the solution that we would accept because maybe that wouldn't be right for all projects for which is, and I think we would always be asking a project why it needed a steering committee rather than having multiple organizations represented amongst the maintainers. So for good reasons why that's the case for a project, you know we should be open to kind of, I think the steering committee model is a creative solution to, you know, addressing very much the first of those two points that Josh mentioned that the one about ensuring that the project is open to contributions and that the roadmap isn't entirely steered for the benefit of one company. I think the types of steering committees are also a little bit different across the projects because if you look at the Lingardee steering committee it's an end user steering committee. So it doesn't actually have. It doesn't have much say over the technical aspects, like the Kubernetes steering committee does so it's it's a different type of steering committee. So, so we're also not necessarily specifying what type of steering committee we're talking about so I think there are multiple types depending on the project. Yeah. Yeah, I think it also depends on the, the founding organization, maybe the founding organization is this really stable company too so I mean, would they need a steering committee. I mean, in the case of Kubernetes you know it's Google right so Google. I'm sorry like Kubernetes has a lot of you know different organizations contributing right so that's not a good example. I mean, I think the Kubernetes is a really interesting sort of mental experiment that you know you'd obviously had its roots in Google and Google is still a huge contributor to the project but if Google were to, I don't know just suddenly decide that it was not doing anything in the world of Kubernetes. The project would have, you know, some serious gaps to fill but I think it would still carry on I think that's the sort of the level of the risking that way that we would like to see and I think it is harder for a project to demonstrate that if it doesn't have contributors from or maintainers from from lots of different organizations. And we do have projects with like a pretty low bus factor as well where you know there would be a serious risk to the project if a particular you know, particular individual that they'd have. Yeah, but hopefully none of the graduation projects would just not survive you know I think we want to be in a position where the graduation products can pick themselves up dust themselves off after a catastrophic disaster like that. Liz would it be fair to say really this is about the longevity of projects and trying to guarantee that. I think so yeah. And I think from the TOC perspective it's less trying to be prescriptive about how to do that. It's like these committees are one way to do that. But it sounds like the TOC is open to kind of other options, as long as kind of that end goal is met. And that's why it's not a requirement per se. I think that's that's well articulated. I think GRPC may have some similar. It feels like there's some parallels between GRPC and that. Do we have any GRPC maintainers here? Yeah, I'm here. Hey April, hi. Hey Liz. I have to give a big plus one to what Ginger said. GRPC kind of went through a similar experience of you know feeling kind of like the goalposts requirements were kind of moving and changing on us. It was kind of hard to commit to that big governance overhaul like Ginger was saying as well. So from the GRPC perspective we're also in that weird spot where it's a library. So you have the core that is heavily supported by Google, but you also have the dot net implementation that is heavily supported by Microsoft and you have the Swift implementation that is done by Apple. So, you know, it's, it's kind of hard to say that like in your example of Kubernetes if Google were to just decide we're not going to do GRPC anymore. You know, there's still companies that would keep the project would still going, keep going. I mean, people are using this in production. So it's just kind of this weirdness of trying to solve for whatever the particular maintainer requirement was, and not really finding a way that would really change. You know, it's our, it's our opinion that we do have the maintainer diversity. And, you know, I think also one of the things to consider when we talk about steering committees and everything else is like what is the problem we're actually trying to solve. The maintainer diversity is one thing I think we all are feeling that especially post pandemic a lot of projects are, you know, seeing that there's also the, you know, when you talk about the longevity issue. You know, there's two things one it's open source. So it's always if the maintainer steps down to hopefully someone else will pick it up and run with it. And that's also I think why we donate to CNCF is so that there is that community of people that care about a project and would let it go. I mean, you know, keep it going I think that's kind of the advantage of doing that so that's kind of my thoughts. But from gRPC's perspective, we are very much, you know, engaged with the community we have a well documented process for putting in a new feature request we hold ourselves to it just as much as everyone else. And I said, you know, we've got great maintainer Microsoft in particular has just done a fantastic job supporting their dot net implementation. So we certainly work with others and we are very much used in production so. Yeah, I would say and maybe I'm not looking in the right place I'm just looking in gRPC gRPC and the maintainers. Oh there is one Dropbox maintainer. There are three, there are three, there's one from Skyscanner and one from somewhere else. Yeah, and that's just more implementation I mean when you look at the dot net. It's pretty much all Microsoft and that would be in a different reply with it. Right that's the that's the problem with gRPC is it's not just one maintainers file it's a maintainers file for each language implementation. Yeah, yeah that's has the same issue with regard because we are an entire, you know, Oregon GitHub and we have, you know, 30 some clients that you know complement the not server and are required for the not server to work in production and we have contributors from individuals to different companies that contribute to all those different clients as well as connectors that are not in our necessarily our GitHub organization, but they are, you know, all over the community so. Yeah, I think that's one part like you know with obviously nets went for graduation before gRPC did but we both kind of hit the same spot in the process where we are different than, you know, a traditional project since we are kind of that library structure, and that's where we both have hit that same kind of pain point of no if you look at the core repo, you know, there, there is largely Google maintained, of course, we're running it ourselves in production. But when you look at, you know, the other repos there, a lot of them we don't even know, you know, the Swift repo I'm not sure what Apple's up to with it and that's fine, you know, back into history and this is an X member of the TOC and, you know, so who no longer, you know, has a has a binding but I recall there was a concern. This is historical so hopefully things have moved on. There was a concern that it was hard to get proposals accepted into gRPC unless you were from Google. I don't know, you know, a fair concern but that I remember being brought up. I mean I would, of course, ask for an example, which I realize it's historical. Maybe the way to address that is to say well here are some counter examples here are things that have been proposed by, you know, people outside the organization that would, I think go a long way to addressing that. Yeah, I mean it's like I said it's kind of two fold again of, we do have a documented process for G a G. Gosh, it's too early gRPC gRFC, because we like our acronyms. So, you know, you make the proposal you fill out the standard document, kind of similar to how the TOC does we have a two week process, you know. So no, not everything is going to go through, but you know we we definitely have a well documented process and other things have, and then that's countered by that's one library that is, you know, particularly strict perhaps. You can counter that with, you know, when you look at like I said, the Swift repo, the Rust repo, you know, those process they have the same process but you know the level of getting something in in terms of a new feature is probably easier on some of the newer repos that don't have as much of a legacy code issue. So I think that's you know some of it like if we keep going back to the main repo which is the C, you know, that's got a ton of technical debt and other issues. So it's not necessarily as easy to put in a new feature as it would be in some of the other languages and that's not a project specific barrier that's just that particular you know technical spec. The GRFC proposal website though has the governance of this list one specific person as the approver, unless someone else is assigned doesn't seem to be seems seems to have a specific named individual as the approver for all GRFCs, which doesn't seem a very open process. Let me check at that because normally what we all of our GitHub is set up with teams. So I'm wondering if that's just a technical issue, but I will check on that but no it's it's it's all reviewed by the same maintainer list. So it could just be a, I will double check on that but yeah it's all, and I think in the governance. There's a separate governance md that describes the process more, but if we have it, not properly documented on that RFC page I will update that. So thank you for calling that out. I feel like, you know, time has you know that's that's clearly a thing that needs to be to be addressed but you know that doesn't seem insurmountable. I wonder whether we should be well first of all let me just see if there's anyone from the TSE here today who would be interested in sponsoring GRPC. Through the process subject to things like this being fixed up. We don't necessarily have all members anyway. I could probably do it. I once I've finished my incubation. Great, great. Okay, so that sounds like there is appetite there to dive into this and see whether we can't find a way for GRPC to sort of answer those questions about longevity and risk. Because I think in many other respects it's an extremely, you know, widely used project. Yeah, and I guess I mean it feels like we're kind of coming back to we're having like I'm not sure what more we we need to do to address the longevity and risk. I mean, you know, that's the nature of open source right everybody's a volunteer so I can't guarantee in the future that if we were to just suddenly stop working on GRPC I can't speak for anyone else. And guarantee it would continue on. So I don't know if that's that's the piece that I feel like, you know, if I can speak for the Nats folks as well like we're feeling a little in the dark on exactly how we're supposed to solve a, you know, the longevity of an open source project like isn't that the whole reason we make them open source and donate it to a foundation. Maybe one way to think about this is how would you if you had an end user company who was relying on GRPC or on something else that was relying on GRPC how would you articulate to them. You know this is a. This is something we believe you can depend on, you know, like you say it's open source it's not like things are set in stone and guaranteed and it's not something you pay for but you want to have some. And you don't answer this now I'm saying I think that's that's maybe a way to think about like articulating it and saying this is why we don't think it's at risk, if this happened. This is what we think would be the outcome. Well and that's what I think like having that requirement for graduation that it's you know used in production like well. That's why I don't think it's going to go anywhere because it's being used in production at Google and Netflix and you know a lot of big companies that are involved in the CNCF as well. So I mean if I was speaking to an end user that's what I would say and I think that's how they've adopted it. And that is even with that like there's always that inherent risk of open source like anytime you bring a dependency and who knows. I think we all recognize that when we do when we use open source so that's the piece that it's, we're kind of constantly coming up against this and. And of course I mean this is this is where the you know the multi vendor thing addresses the risk thing to some extent because it basically says you know, if one company decides not to participate anymore there are other people who are still interested, we think you know we we have that you know, so that could well be the you know sufficient answer to that question. Speaking as an end user. So, for example, Kubernetes. I know there is a lot of involvement from vendors like VMware and red hat, and that gives a lot of trust. And I'm not talking about the technical contributions. And if in addition to project adoption by the vendors or contribution from the vendors, there would be more trust. I hear you and I what I'm saying also is for like I feel like on grpcs perspective and that's as well, we have, we have done that. So, but we're still coming up against this, and we have for years. My sense is April that, you know, time has passed things do you look very stable there's, you know, a lot of usage of grpc so I, I don't want to prejudge anything but I think the fact that Justin has volunteered to put that on his Q is is a step in the right direction towards graduation. Great. Yeah, happy to, you know, let's cross this off the list come on. Yeah, let's go. I have pancakes is ready pancakes has a cap and gown he is ready to go. He's an adorable little dog mascot for grpcs like he's ready. Yeah, excellent. There's your incentive right there you get a sticker. So, yeah, wonderful. Thank you. All right. And then Falco, which is a considerably less long in the two applications and the grpc and that's one so. I think I saw the Leo on dance here so we have some folks here from Falco. Yeah. One of the Falco maintainers. Yeah, we've definitely been in the queue less than the other projects it's been probably at this point around four months something like that in a general way from our perspective is more like like waiting for guidance understanding from the to see what's your view. If you if you think we are ready. And if yes, if somebody would like to sponsor us if not, we'd love to understand what we can do here to move the project in the proper direction direction to our graduation. I guess I had put a few thoughts on the PR for this a few days ago. I would say at the moment, it feels to me like it's not as stable as I would like to see. I'm not saying it's unstable but I would like to see kind of a broader set of maintainers and students over time through, you know, if I if I compare it to, if I compare it to that so grpc for example the the number of people and the, the the momentum behind it has been. I guess it just doesn't feel as established for graduating projects. How would we measure it and what would you like to see, we've seen in a general way, pretty strong adoption of the project including several users using it to scale in in production. We've documented some of them in in our PR in a general way this point. Yes, you know, since this is the company that originally contributed it but the community, we feel it's pretty healthy, pretty much this point largely on autopilot we have constant discussions, like constant contributions, including contributions from our, some of our direct competitors that are participating to the project we have many companies with commercial products, basic basic solutions on top of palco. So, what, what can we, what can we show you. Can I kind of add to this and sorry lords, I can just add to this. And there's also if you look at our adopters file. And by the way, I'm Dan Papandre, I'm the director of open source community and ecosystem for Falco. And so if you look at kind of the adopters file and also like, you know, if you look at the names in terms of hyperscale you see like the AWS and red hats of the world I just was late to this call because I was on a call with Microsoft are looking to integrate us from the, from the Azure perspective right. And so there's that. In terms of main maintainers that are you know external to statistic. Again, it's when you're created the project you kind of have to spare the special spearhead especially because of the interesting, you know, like the introspection point that we have with the BPF and those types of things there's a limited set of folks that understand how to do that. We've made it very much inroads with the Falco sidekick project with which has, you know, many external contribute contributors and so much in fact that we've created seven direct blogs that have integrations to things like, you know, Prometheus, Open Fuzz, you know, Tecton, Argo CD, which is also a project looking to get graduated so there's a lot of community integration and also we're seeing maintainers that are of a wider, a wider main maintainers base from that perspective. So we're just looking at it this like, yeah, I think we're much more established than we were during incubation, for instance, if we look at it for docker pools, for instance, it was from 8.2 million docker pools as of this morning to 29 million. So we know this project is being used. So we just want to understand from the talk, what is our next steps what can we do to put the talk at ease for either one for us to get a sponsor or two for us to graduate, or both. Personally, I mean, you know, unfortunately, you have the disadvantage that I know a little bit about the space. The sidekick, fabulous, wonderful that you have people contributing to it but people contributing to sidekick are not necessarily going to be able to maintain the EBPF code or the kernel module code if you're using that side of things. I mean, if I look at the contributors to the core file code code, you know, that it's, it's pretty cystic dominated we've talked before about how that doesn't have to be a blocker that can, you know, there can be ways of having steering committees to ensure that, you know, the project isn't that's been driven for the benefit of that one commercial company. But you know if I look at, again, you have the disadvantage that I know some of these people or the fact that two of the top three contributors have moved on and they made it they're still contributing so that's great but I would want to see them contributing over a period of months to say that that's actually stable. On the EBPF side again we've made inroads talking to other projects that are using EBPF and as mainstay projects of this so if you look at like we've talked to like it for instance from Tracy to see if maybe there's ways we can come up with a universal rule set or contribution to like you know he asked us to look into creating a driver kit update so we can all have a standard place there that's one in terms of, you know, like we talked about before and you're in this space and you understand this it's very hard to find folks that understand EBPF, you know, XDP all those types of things and so, you know, that's something that, you know, because we, you know, cystic has that underlying expertise, it's and as I'm sure the same as for Isabel or Sonia. I mean, I'm currently doing the incubation review for Sillium and they have nine external contributors contributing to the core. Those are people who, you know, will be working with EBPF and I've been talking to end users about EBPF and that's not the part of it that they have problems contributing with because I asked explicitly about that because it's obviously an issue so I actually don't think that's an excuse for not having maintainers on the EBPF code. That's a fair statement and again it's also I think having like CNI integrations as well I mean is this specific to EBPF capabilities or just overall. So it's more just looking at the, you know, if I look at the core code, you know, if I look or if I look at the core repo, knowing that, you know, I mean, I'm just looking at the grass now I'm going to guess that two thirds of the contributions in the last month came from people who've recently changed from cystic to something else. I'm just doing that by I don't, you know, with, you know, and that's great it's fantastic that there could be another company supporting the, you know, the project going forward, but I wouldn't want to, you know, say to an end user that that's it's multi vendor it's the risk I want to see that over a longer period of time. Yeah, that's that's my honest opinion of it is it just doesn't feel that we have an established stable group of cross, you know multi vendor contributors at this point. So you can get that as we can find people to contribute to, to that and you know if for example, and you know collaborating with aqua comes to pass that would be a really good way of, you know, having a multi vendor input, but I just don't think it's there yet. What would you like to see at this point trying to understand you know what the next steps for us could be and what, what, what can we do here and what can be the metrics for us to be considered worth graduating. So the, the criteria require the TOC to feel that is sufficiently mature, which is a pretty, you know, subjective measure, but that allows us to, you know, look at the maturity of different projects along a lot of different axes. As I say I just have this flag right now that the core project has a small number of maintainers, those maintainers are almost exclusively from Cystic or just left Cystic, I would want to see over a period of months, some stability around that and never a continued activity to, to make people confident that that is a project that isn't just going to get parked. It's not the answer you want to hear but that's mine. Yeah, I think it just needs some time. So in practice this means we come back again in a certain month, a month of months, and if yes what would you recommend these amount is. I think usually when we've had situations where we've suggested people go away and come back again it's usually been sort of six months. And there could be other people in the TOC who disagree with me, I, you know, it's not just me, I feel a bit like I've done a lot of talking. Yeah, we recommend to check in with the TOC periodically, maybe once a month or something like that and see how the project. I think once a month will be pretty, you know, pretty frequent for us, given the rate of things that we get through. And once in two months or something like that, I don't know. Yeah. Yeah, I think there may be. Yeah, go ahead. I was going to say is there like a tag maybe that they could sync up with to be to do those kind of regular check ins or think that's the thing that Laura said in the beginning that we're kind of confused by and we're trying to figure is that process right it's it's kind of like now we have we've heard this now right and now we know what we need to do, but this took X amount of time and I know we know you ever talk as we understand that. As much as we might disagree right and we still have to make sure that we're following the talk process because we do want to graduate do feel that the adoption of this project is is is making this thing like where it's, it's a project out there so we will continue to do that so I guess the question more is like, what, what is the periodicity should we should do check ins for this. And, and, and what would you like to see to avoid the being in the situation again. Is it specific to this or is the is the goalpost going to change at a given point so if we come back and we have we get we have more people contributing at the core level we're at the ebpf and all those things is there other things that we have to address. I can't speak for the whole to see I can only tell you what I the concerns I have. And, you know, in, I mean I would say maybe you know, six months seems like a reasonable period of time for things to have a, you know, if you came back and said actually yeah look at this, you know, it's the same group of maintenance but now they're working for different organizations so we kind of proved that multi vendor thing and it's been stable for six months and you know an adoption still going up that would feel, you know, more likely to, to kind of meet the criteria you know equally in six months time, you know, maybe I wouldn't be on the TOC anymore maybe it'd be different. I can't guarantee to you that they will, you know, the TOC would agree at any particular time that, you know, because because it's always going to be a judgment call. The criteria are we know we're trying to write down the criteria to the best that we can but it is a judgment call in the end of the day. And we want it to be hard because we want the graduation to mean something, you know, for, for end users. There's no denying the, the adoption of NADS, GRPC and Falco and they'll continue to be adopted and used regardless of, you know, again we really appreciate the, you know, the graduation kind of spec and all that it's awesome we love to hear and that's the other thing we just want to make sure that we understand what is necessary to get over there so there isn't that, you know, that object and trying to promote a project so let's let's figure that out and we appreciate everyone giving their feedback here. I think where we have had historically concerns about projects a lot of the time it's come down to this. There isn't multi vendor multi organization maintainers, you know, some projects demonstrate that very clearly I mean, you know kubernetes is a fabulous example for that. You know, projects don't do that and different TSE members have historically had stronger or different feelings about how, how crucial multiple vendors is how we, you know, we understand I'm sorry to interrupt you but we definitely understand that we do have aspects of multi vendors and in terms of the maintainers aspect on the core side it just seems like that seems to be the reflect the inflection point at this point maybe if I'm missing it right or wrong but it makes sense. Yeah, yeah. Yeah, I think that's from my perspective. It's also trying to balance as a project, the future of the project because in a general way, being part for a very long time as the potential to for example disincentivize people from from contributing or using the project and essentially understanding what the rules are because as you were saying these rules by nature are subject to interpretation so that makes it more complicated for us to just, you know, exactly understand what to do and how to do it you know we're committed to do whatever is required, but clarity definitely helps us and minimizes the potential damage that is done to the project. Yeah, I'm not quite sure where the damage comes from but, you know, because CNCF is still, you know, it's an incubation which is a pretty big, you know, sign of confidence and support. Yeah, to give you an example, there was a junior developer in the project that started making contributions and wasn't sure if this was the right project to contribute for him based on the uncertainty on the future of Falco. Okay, so I'm going to turn that round to you and say if there's a junior developer contributing to the project who isn't sure about the longevity of the project. It's reasonable for me to have like, okay, you know, is that ready to graduate. You know, you know, the CNCF's role in this is not to provide the de-risking. The CNCF's role here is to support the project in incubation such that it can get to a place of de-risking. Yes, again, we're committed to do whatever is good for the project and we'll do our best to do it. Wonderful. Is anybody else? I mean, we're almost running up to the hour. Does anyone else have anything they want to say about Falco? I'm just wondering if there's anyone from Six Security here, for example. Yeah, and I wish there was a way of being able to sort of articulate that saying that a project is not, in my opinion, ready for graduation is not, it's not like a vote of, you know, I still have confidence in the project so I still think it's a good project. In terms of tag security, just one kind of note further talk, we've, we're kind of almost a gold standard for the vulnerability assessment aspects and those things that have been done. So, like, I've been told from members of the tag security that, like, it's really was done well from that perspective. So I think their concerns in terms of, you know, the vulnerability that they've looked into were addressed as part of this initial process. So if you look in the PR that has that being addressed, so I think that should be less of a concern. Obviously, we'll run into that as we go. But that's definitely something that we've, as a security product, we want to ensure that we're addressing. And again, we appreciate the talk giving us the time to be able to speak about Falco because we feel very strongly about it and we'll continue to feel strongly about it. So we know it's a product, excuse me, it's a project people are using and people are contributing to and are adopting. Great. Keep that up and see I see we'll want to graduate it. All right, so we definitely didn't have enough time to talk. We didn't even have time to touch in on the incubation. Actually, we've got like one minute. Okay, so does anyone who's on the call, any sponsors want to make any comments about how they're getting on with the incubation and due diligence. If the sodium is nearly done, I will be bringing it right soon. Question on virtual cubelit because I know that's been out there for a while. I think I still have no, okay, change drop the call never mind. No, I'm here. Okay, sorry, carry on. Yeah, I, I mean, there's a virtual cubelit community meeting actually on Thursday in couple days. So I don't know if anyone from that community is on this call but I intend to attend the virtual cubelit meeting and have a discussion about the, you know, the issue is really compliance. What's the current situation, what we believe should be the should be the right stance. You know, at least I want the project have a strong opinion of this, then, then I could bring it back to TLC to have a discussion, because right now we don't seem to know where we really are clearly and we have a strong opinion. That was the question of compliance with like, what is a key with, with, yeah, with real cubelit with the non virtual cubelit. The virtual cubelit has a lot of implementations but but but they're they're complying in various different ways. So, so it's very tricky because how, how, how strongly do we hold compliance anyway so I think we've talked enough. Okay. Please feel free to reach out to me if any, any virtual cubelit members on this call and maybe we can have a chat even before Thursday's meeting. I hope that, I mean, I think talking about, well, I hope this is this has been a productive meeting. Thanks everyone for joining us. And yeah, see you next time. Thank you, Liz. Thank you. Thank you.