 Hello. Excellent, we are recording so let's get started. Alright, so we'll start with the reapplying projects and I think you're up with the first on the list. And so I, as I understand this applies to your and it also applies to another project on the list. I think this is library components rather than standalone and please correct me if I'm wrong in understanding that. And I'm not sure whether we have projects that include client libraries but I'm not sure we have any projects that just are library code and I feel like that's a, you know, that we should consider whether we want to. I think first of all, does anyone disagree with my belief that YARP is library code rather than a standalone project. Hey Justin, we've got Justin as well. Sorry I'm late sorry. We were just starting to talk about YARP. I'm saying that I believe that YARP and also another project which I will will come to at some point, but another project on this list is library code rather than a kind of standalone thing. Which might be okay but I'm not I couldn't think of anything that is library code might we might have client libraries as part of the project but I couldn't think of anything else that just is. It's something we want to consider in terms of whether something is appropriate for CNTF or not. I mean the first question is why wouldn't it be. I suppose that my thought process on this kind of came through well, you know, does this particular solution that's, you know, C sharp. I mean that's, it's perfectly valid for people to write applications in C sharpen.net. But do we want to be. I just thought GRPC is a library. Is it. Yeah. Okay. I think it is actually I was actually agreeing with you and then I was trying to think through project but I think GRPC is strictly a library isn't we didn't bring in a spec project. It's it's a multiple libraries for different languages but it is definitely library and that's how you consume it and that it's unusual. I think because cloud native projects are often consumed as services or shared as services but actually it's not totally out of. One another yardstick is for GRPC, we have so many different projects that use GRPC right here yard is coming in and there is no consumer of yard as such. So that's the distinction between the ARP and GRPC I guess. I don't think we really use that yardstick for sandbox as much since it's supposed to be for incubation and innovation. I have to believe that it is a good fit for the CNCF and I guess I just when I and I appreciate that GRPC maybe already is the precedent but I think I was, I was worried that we're going to have. It opens the doors to a lot of, you know, library code that is some small part of the cloud native, you know, functionality and whether or not we really want to be drawing a line outside of that. I don't, I don't know, I think I'm partly struck by just the sheer number of projects as well and wondering whether we're making things easier or making things more confusing by including yet another class of project. No pun intended on the name. Do you think there are kind of justification for why it's not in .NET foundation and is kind of weak? Yeah. Because it's, it's, I mean, there's the comment and the linked issues, which is just kind of like we want to make it more, we want to bridge .NET and cloud native and it's like, that's great but it still feels like one component out of many is in would be in CNCF and everything else in the .NET ecosystem is in the .NET foundation and it just feels kind of weird. Yeah, that seems like a reasonable argument. Well, the other way to think about is like how many, who will be using this and how many of them will be using it or like, how is it going to spread, right? To be useful in the CNCF ecosystem and do we see projects depending on this that will essentially go into any of our usual deployment models and things like that, right? That would be the fit that we look for and I don't see it yet. So perhaps as Chris is suggesting the .NET foundation might be a more suitable foundation for this. Why can't I see the, why can't I go back? How? It's like I'm new to computers. What happens? Sometimes, just sometimes. Why can't I see the, maybe that's what I need. Except, ah, there we go. I need a whole lot of tabs, right? It's also not clear to me who the maintainers of this project are and how, what its governance process is. It does not feel to me like it is a very natural fit personally. I mean, it's very much a Microsoft project with a Microsoft CLA right now. And I'm not sure it's got non-Microsoft usage. If we don't say no to this, what else will we say no to, right? Yeah, yeah. Do we want to hold a vote? Shall we, or does anybody feel that they would be voting yes? No. We should just do a vote less and say no. We probably should. Yeah. Okay. I agree. Yeah. Well, and it's not just the Microsoft comment either. I think it's just, it's not a good fit for what we see being a viable project. Yeah. It feels, I think this, this whole question of, you know, how it fits with other cloud native, you know, if there's nobody else already using it. I mean, the, I do think there is a question mark over laundry projects. Dotnet feels like a more sensible home for it. All right. Is that enough? Okay. What was the next one on the list of repeats? See you please. Pixie. So, Pixie have definitely, when Pixie came up last time, I was concerned about them having a link in there. GitHub to their self-hosted, sorry, their own hosted version of Pixie. And they've sort of, they've made some improvements there. They've, it's not like on the first page of the GitHub, but there is still, and I kind of understand why they have it, right? I think it's quite hard to set up your own hosted version of Pixie. So that's kind of saying, you know, for an onboarding experience, come to our version that we already host. It is not clear to me who is operating that. And, you know, it is still not unsurprisingly, it is still linked to quite heavily from the kind of getting started documentation. Do we have any other examples of something where the project hosts a version of the solution like this? It's like a demo backstage server, but that's a little, a little different, right? Well, it's whether or not you have to sign up. Yeah. Artifact hub is the only. An artifact hub is operated by CNCF, right? Correct, yeah. Yeah. And could we operate this hosted version of Pixie? That's a good question. Potentially would have to figure out what the costs are, but having other vendor, I'm assuming they're done in a way where other vendors could go operate this on their, on their own if they wanted to. Presumably. Yeah. Yeah, I mean, they have got like the full, the repo has apparently everything that you need to run your own version. Does anybody run it already? And users, they do it? I know there's an AWS collaboration. I'm sure New Relic who bought Pixie is doing something with it. I assume New Relic are essentially hosting the. Yeah. They paid for it. Yeah. And I think AWS said something that they plan on, at least contributing to the project. Yeah. Which is cool. And I would really like to find a way for this to come in. What I'm worried about is the precedent of, oh, you know, you can operate your own website and essentially have the CNCF funnel you people who sign up for your. That we would not allow. That is not allowed. That's against our policies. You can't have like a sign up form or, or harvest, harvest emails that way. Right. That's a demo server, like a backstage thing. That's completely cool. All maintainers have access to that. My assumption is here they probably just do like a demo thing running on the CNCF cluster. Right. I think that's probably what I would do and I'm guessing New Relic AWS others will offer probably hosted SAS based offerings for this. Yeah. Yeah. And probably like other things if there's like a hosted version of something their project page can, you know, so long as it's prepared to list all of them it can list them. Yeah, alphabetical order, just like envoy and a bunch of other projects that that point. What did we ask them last time. And they came here to revisit. We asked about whether it was all the repos being open source as it is. Yeah. And I think they were forming this type of governance structure. Also. Yeah. Yeah, so I'll show you the thing. I mean, you know, it's not. I completely understand why this is here, but you know, you go through quick starts. Yeah. And, you know, it tells you you can. I can't even find the version of here we go. You know, there's this pixie community cloud, which saves you from deploying it. And which is on with pixie.ai or maybe pixie labs.ai or both, which are not listed in the domains that they're going to transfer to CNCF. Yes. And so then you end up here with a login. And so the question is, is with pixie and pixie labs are those to make what is going to happen to those domains in the name. Because if they they get to host a pixie service with a with pixie in his name and other people don't then that's a problem. I mean if it's just they manage service for this and it's alive and so that's fine, but they can't presumably do under the trademark of now. It would have to be, you know, New Relic, blah, you know, with pixie or for pixie type type setup. Yeah. So the only other thing I can think of is a rename pixie to something else, and we get to host only the sources. We don't care about the website or whatever service they are running. Well, I think I think we need to just get them to clarify what their plan is going forward with this and what what the brand what the branding of this would be and that it will be a pixie service not the pixie service. The trademark there for sure going to transfer over that I have clarity. So it's just a question of like you know they're whether this demo service runs on the scene if you have cluster or New Relic or AWS offer their own like hosted things which is fine as long as they name it, you know, appropriately, right. One thing I don't know if you all have noticed I was just flipping through this, the docs. So when you start on the doc that is linked from the application you are on a dev site. If you click on the link to the, the hosted if you click on the pixie community cloud. You move over to a AI site. Yes, the documentation looks exactly the same but it's all under the southern domain. It's not on the list that's being transferred whereas the other ones, right. Dev and pixie.io are listed as being transferred but not not the other all the rest of the dots are under that.ai and they look exactly the same the table of contents doesn't change everything else. So it's pretty sneaky. Well, I mean I didn't say sneaky I think it's because this was this service that was acquired. It's being open source so I think it's okay to have transitional issues but we need a clear delineation of what's happening I think. Yeah we could ask them about the domain I think pixie.io was the name of their company, I believe. Yeah, that was purchased. Generally we would ask for that domain to be transferred over as part of the process, but if they're not using it in any fashion. Then we don't care as long as it's not as long as it's not confusing to end the end users that get that it means no longer being used we don't care. But the just in points I view this as like a transition thing we're, you know, as part of onboarding, we kind of deal with this whole thing there's, you know, we've run into other projects that we have to explain to them how like you have to list all the services that you know people are building upon an alphabetical order and a fair, fairway and so on so I don't see anything too crazy outlandish here. So do you think we can go to a vote with the sort of provides though that they would need to resolve this community hosted sites and the use of with pixie.ai and the, you know, the signups here. The interesting email is like you just can't do that, right there would have to be some other, you know, if the if the New Relic runs our own service they could go for to their hearts content right but it can't be. You know something that they run with that name. Right. So should we have a vote on the assumption that those things are resolved as part of transition. And because they have to be because otherwise they couldn't be in the scenes yet. Yeah. Okay. Okay. So I think the next. We can probably talk about them together there's measuring and SMP which was service mesh performance. And so, when we discussed this last time we were talking about how, you know, we have the service mesh interface already we have service mesh performance, and then measuring which kind of implements some of these things. We went to SIG network where we have the interesting scenario that SIG network is essentially being run by Lee and he's also involved in all these projects. I guess the good thing about that is he knows what's going on. But he did go out and have a conversation with lots of maintainers on the service mesh interface project and measuring and SMP. I think there are a couple of things that we've learned from that one is that SMI is the potentially an at risk project I would say it's not going from from what I hear there are some issues there in terms of its support from its own maintainers. I think there is some potential for SMI and SMP to be kind of better aligned. There is interest from people outside of the existing maintainers and some other companies who want to get involved in SMP and want to see it in the CNCF before they do so. And then measuring the project I would say is very clearly saying we are much bigger than both SMI and SMP and we want to have a life independent of those two spec projects, which I think is not unreasonable. So my own feeling is that yeah we should treat measuring sort of you know separately. SMP seems like it's one of these areas of experimentation and collaboration. And that we should be signaling to SMP and SMI that we want to see you know if we're going to have like a definition of what service messages are let's try and make. I don't think we're going to see one of them. We're not going to see both of them incubate without a very clear agreement between the two. That makes sense. So do we want to work for measuring separately right now. Yeah, I think we should be voting on both measuring and SMP as separate sandbox projects, and then if they pass I think we should be signaling through SIG network that we want to see SMP and SMI, you know, not diverge at the very least not diverge. Does anybody else have any other sort of points they want to make about either of those two projects. Okay, should we do votes for let's do measuring first. I think you've sent me a vote directly. Oh, Aaron, if you send it over and main wheel, we will pass. There we go. Thank you. Great. And let's do votes for SMP as a separate project. Oh, and I've sent it to everyone. Again. All right. So now we can go back to the top of the spreadsheet and the new applications. So Porta LB. And noting that we already mentioned metal LB I think there's, there's a couple, maybe three, maybe even more load balance projects all throwing their hat in the ring at the moment. So Porta name collision seems to be a bit of an issue. I mean, I'm sorry, I have an issue with them not filling in the form. I know what you mean. Yeah, it's mostly it's mostly blank. I'm sorry. That's a hard no process. Yes, not having made the process really minimal but if you can't, if you can't do that then I'm sorry. Do you want to vote for that or do we want to just bounce it back some say a you would have to change your name and be you would need to complete the form. Yes. Yeah. Because if they did both of those things we might in future accept them. But given how many different load balancers there are, are we going to have a stronger differentiation at sandbox level than we would normally or not. They haven't submitted the difference between the other load balancers for better metal like metal, for example. So I guess I guess what was, I guess what we're saying is we can't, you know, we can't really consider the application very thoroughly because they haven't really filled in the form. And it's always possible that there will be more competition and we might not accept them in the future because you know there's no there's no guarantee and there might be too many load balancers. So we have this, we have this field explanation of alignment and overlap with existing CNCF projects and it's optional to make the requirement. I'm not sure why it's optional in the form. The description is an option is it. The description is not but how did they get that. Yeah, we should we should ask them to fill in the description part and as you'll add the explanation of the overlap, I think, although they are optional, but I think they are very useful information for QC to make sense. I think so too we have so many projects and it's important to understand the overlap with existing projects to see how it differentiates. I agree. Yeah. Can we make that alignment field into a non optional. All right. So, shall we move on to cube veiler. Just one question on the previous point. Are we surely didn't override the content after the submission. Because I think this is edible. Oh, you think maybe somebody has inadvertently changed it. There is a deleted. Okay, is there. Because if you tap space on it, so it just warrants the whole thing. Oh, that's interesting. But it appears to just say border LB as an open source load balancer implementation designed for bare metal keeping as these clusters. How did you find that. Right click and there's a show edit history new. Yeah. Just created just in time for this meeting. Nice. All anonymous users deleted it. It doesn't have a way of responding as far as I can say. Loan days ago. So they did. Yeah, I was just testing now and actually you can just mistype something in just a while. Yeah. Okay, that isn't fair on them. I still think it doesn't change the naming issue right so. Yeah. So they would have to change their name. I mean we could vote on whether we want to accept them on the assumption that they do agree to change their name. It, you know, it's got. It's got some interest. I think there is the fact that it comes from a cubes cubes for distro. Does anyone know the major differences between Porter LB and metal LB and any experience. I see both of them have applied. I have, let's say come across not used myself but I have been sort of adjacent to some usage of metal LB. Which I think has some some good points and some. I have heard people concerned about scale but you know that is probably indicative of the fact that they've been using it at some scale so is real. Oh James you're sending us a link to comparison of the two is that. There's not much there but you know, how is it packaged and how is it uploaded that kind of stuff. Should you request project owners to submit the difference or explain the difference. But then we have to go tell both of them right like. Yeah, yeah. And we have usually, you know, we have that idea of the sandbox being potentially a space for competition. I gotta say something else I didn't love was the fact that they put on their read me they put the CNCF logo, because it's been accepted to the cloud native landscape. I hadn't seen that done before. It feels a little bit cheeky. Yeah, I agree. I'm also a little bit unsure about because it says it's a sub project of cubes fair is it. I mean, it cannot be a sub project of something that's not in the CNCF once it's in the CNCF and how independent is it. It is keeps fair potentially gadget wasn't joined the CNCF. Because it seems like if it's a sub project then it's saying it's not independent. Right. And it seems like it's a consulting company. Who is to fear. Does it I thought I thought it was. I think it's a distro. I mean it might be a company. It is a company added distro. You can think of it like wrench or China something like that. That's fair enough. The only other thing that I can add is, I haven't, I didn't run across the name in any of cuban it is related mailing lists or, you know, repositories or anywhere else so brand new to me. I guess also I mean there's a there's a language thing I mean it's a sub project of cubes fear but if it's if they had phrased that as. I don't know, Porto LB is a project created by cubes fear that would be that would be okay and we would assume that means well they were the founding makers but they decided to contribute it that that would just be a transitional thing would know. So do we work now with the caveat that will work through the separation concerns later. The owners are a subset of the cubes fear owners. But I think that's okay for sandboxing. Yeah. Yeah, if it's intended to become independent. And it's, I think I saw separate installers for standard open shift cuban it is and K3S and things like that. It's right in the main page. Yeah, yeah. See, yeah, Kubernetes K3S and cubes fear. Right. Yeah. So from that point of view I think it's, it's okay. What's it called? Subject to name change. Erin yours came to me again. I don't know why the chat keeps doing that. It's not like Erin and me are having like some really exciting back channel. No I clicked chat and then it just, I don't know it suddenly selects you so apologies. And then it defaults mine to sending back to you and yeah. All right. Okay. acceptance or does it need a quarrel vote and a majority need eight. Do we need eight positive votes or do we need a simple or two thirds majority of a quarrel vote. My understanding is that we need eight out of 11 for the voting. So, given as I do not see a passing vote on here, suggest they change the name and reapply. Okay. I think I saw somewhere that this came out of crossplane. Yeah, my team is involved in this project. This is actually originally a crosspan sub project and then moved to move out independent project. Let's see it like that. The last commit sound looks pretty familiar. Oh, yeah. Um, but so this is being donated independently of the arms back. It's like correct. Everything will be donated together. Basically, I'm back is already coupled with this project like the API implementation. Yeah, it does say in the notes somewhere. Where is the first column. There we go. And the spec itself is now driven by Q fella and considered as part of this donation. Yeah. Yeah. I hadn't come across the application model before either. I have. But yeah, I didn't, I didn't realize, I think I hadn't come and really come across cube fella as part of it. So I kind of the other way around for me. I ended up running into this. And I was looking at like dagger.io and ship.io. So it's in the same category right. Harry. Yeah, same category basically like. So a platform service. At the top of Kubernetes as well as the hybrid environment. All right, shall we anyone got anything else to add or should we do votes. How do you like the people on this team. With a plan B to rename the org to covalent then. Rather than I am deaf. That is acceptable. I mean, I'm not asking. It's just, it seems weird to accept it. Like it seems to. If we accept it as Q Vela, it seems more like better than the August Q Vela. We accept it as OAM. Then it's fine to be called OAM. I don't have any preference, but it's like. It seems it seems just seems a little bit inconsistent until confusing potentially between which of them is the dominant part of it. Yeah, does that every has a life on its own is, is there a potential future where I am is a spec and keep Vela is, you know, just one implementation or something. So, there are actually coupled right now. They are coupled together in some nation, basically like API implementation. So there's no other implementation. I don't think there's motivation to promote any other implementation based on that. Yeah, so the original, the current plan is that the organization move to things that actually it's including every component to make could be Vela to work, including. You can see there are mission controllers, dashboard, it's command line tool, so that is the original plan. How much rework do you have to do to it. I'm sure you have OAM in the imports or something right so that that's going to be your issue. And naming will require some work. That's actually the reason we didn't do that for because it will break some dependencies but if we still is necessary I totally okay. From my perspective, just some technical issues to solve. There's no political or any non technical blocker for that. Chris asks a good question which is does that mean that everything on the OAM dev is. And Harry said yeah, and he said yes. Cool. I mean I'm not worried about renaming I just think it might lead to confusion it might be worth considering that source. I know it's painful. Right, we discussed that before. I don't think the plan to name that but some maintainers raised concerns about that, because we have production environment I rely on that part which will make it, you know, take some time, but I think we can raise the issue formally to discuss that. I mean in GitHub to see if folks okay to renaming the GitHub report. One possibility would be to sort of consider the project as like OAM and veiler kind of, as if they were a combination project. Or sorry, OAM and keep data. I feel like the most important thing. Movie movie docker docker is still going on right. Spiffy spire type of. Yeah, I can understand the organization name is essentially for example like clone native application system of things like that which will make sense to cover what's inside currently in that organization that is actually I hear I will also I will try to ask the team to raise issues about what should be the right name for the organization GitHub organization during the sandbox on boring. All right, the next one is K8 up or K tap or I don't know how you're quite supposed to pronounce it. They said catch up. Catch up. Very good. And I just wondered how much this is really a whole project and how much it's just a wrapper around. I think it uses something called rest stick to do the actual backup bike. It does a, is it enough to build an operator around something is that really a whole project. I don't know. Yeah, I didn't have a full look but actually we, we are looking for a component like this but that does both the backup and restore. It's not as trivial as it sounds. Yeah, I'll plus one to that I think Valero is another solution in the space and they also use rest stick. Okay. And in both cases we have issues with with accident implementation of the persistent volumes and how much support they have for restoring from snapshots and the thing like this. So a general solution like this it's not too bad. I think that rings a bell to me to put is it in the sandbox already. I think so. It might have graduated out of sandbox it's definitely something we need though, like in terms of our strategy of like managing data at that level we don't have really hard solutions in our landscape around these type of things doesn't mean we should accept this based on that. Go ahead, Chris. It's not in CNCF it's I think it's VMware still has it but dims couldn't. I thought they gave it back when Joe was on the CNCF I guess I'm imagining it. Probably another special. Yeah. If there is no consensus for sure. I'll ask. I'll, I'll check check with folks and get back. There is a Chris's comment about having to change the license they do actually say in their kind of column P, we're currently using the BST three clause license but we're open to changing the license to Apache to so I think that would be a sounds like that's only 18 contributors to get sign off to change. Yeah, so not not too painful, but still painful. 172 styles is not massive, but it's not nothing. So this project depends on a restate with the W. And I don't know if that is part of the submission. As a third party dependency can you be a little more clear what you mean here. So there is a one I think link W R E S T I C. And that's part of the same organization. Yeah, I was looking at the architecture and it mentioned that the operator is K top ketchup, whatever the rest of crapper is W R E S T I C so. Right. So I guess there is a question over whether this donation includes the other one too. The more rustic parts. Does it say already. I guess we would want clarity on that. Yeah. Yeah, I talked to them for the crossplane review as well. And, and they mentioned they were they were submitting this project. They were keen on giving more information as well. We need one more piece of information before we can work. Which is whether or not this rustic thing is included. I mean the other the other possibilities to vote subject on to that being included. In general, we've asked for a confirmation about if we are not sure about what's in and what's out. Yeah, okay. All right, let's let's go back and ask that then. BIP VIP. This is another load balancer by the way. Yeah, this one is being used a lot by a lot of people so. Yeah, I have heard this one. 385 stars. I think, yeah, pretty popular with the crowd that does the cluster API stuff. It's a lot of contributors. I mean it's, it's, it's It's not enough. Yeah. Yeah. I look. I mean it's mainly, it's mainly, it's mainly done. Yeah. And Yassin from VMware, you know, he was working with, he's the second one. So he's the one working with them to get it working with Cappy. Yeah, the other contributors are pretty small. But, you know, that's, that's part of the whole reason for sandbox isn't it. Justin, I'm assuming that is a, in fact, a plus one. Oh yes. Yeah. This is just plus one with a shift. The confirmation. Very enthusiastic. All right, the next one on the list is cube DL. Which looks as though it's a kind of keep flow alternative. Kind of intriguing. Another Alibaba project very prolific. Time check though, we have roughly five minutes left in this call. Yeah, we'll just have to get through what we can. Yeah, anyone. 165 contributors and sorry, 165 stars and seven contributors is quite feels a little bit early. Yeah, I just started having a look at it today because they they're very vocal about how the features they have that could flow doesn't have. But then it's true that it doesn't have a lot of contribution yet. So, there's a lot of caution against again, against using that as a metric for sandbox. Yeah, widely deployed inside Olly it's probably has some usage. Yeah, so this project is also my team is partially a participant so the overlap with cooby deal with cooby flow is the cancer flow job CRD. So the cooby deal has its own CRD for cancer flow job. Which is similar but has difference with cooby flow but for other parts, they do not have orbital. That means the cooby flow components can be used to this cooby deal. For example, it's workflow and meantime cooby deal provided several other features which do not exist in cooby flow. So this, this is the relationship between these two project it actually has explanation is really me for example cooby deal and tuning CRDs, a lot of tuning CRDs besides training and serving and they do not actually implement serving. So you can use cooby kinetics to do serving just like a cooby flow data so that so basically like that. Yeah. Okay, why do you want to contribute question it says we at Alibaba have widely been using Kubernetes to manage large scale deep learning workflows for many years, but doesn't actually say use cube DL. I think that means they are using crudely. That's the alter the half. All right, okay. It looks super promising. But then the contributions. As mentioned before, but yeah, the features are like ticking all the boxes. We take this one to about then. All right, we are almost up at time. Let's see whether the next one looks like a really not. Oh, the next one is crosslet. Yeah. So the thing here is go one. Go to the ninth one seven and nine go together less. Oh, right. Crosslet and oh yeah and cradle. Yeah. The question that we need to ask them is, can they work as a single project I think, and not as two separate projects. We see creator as a SDK library for other rust projects, not just for crosslet. Yeah. Right. I think there is a question about that over, over libraries. Yeah. Yeah. So start there and then we'll see where it goes right. We can also we can also ask a question what what other projects use creator besides crosslet is an adoption. So does that mean creator is a dependency for crosslet. Yes. That's right. It is. And written by the same people and submit at the same time. So it's not like it's not that they haven't adopted someone else's thing they've written their own thing but they're submitting them separately. Which is a little bit unusual because normally you would put them together and maybe spin them off later if it seemed worthwhile rather than starting them separately and then merging them later. It's going to be awkward if we, you know, they can't really be decoupled if they would be awkward to have let's say crosslet in incubation but crater in sandbox that would seem strange. Yeah, so maybe going back to them and asking why why crater isn't part of crosslet as a project. So instead of seven for QDL so if anyone else wants to add a photo. They did that. Yes, they did answer that question saying that in the Kubernetes ecosystem there isn't a good library for talking to Kubernetes and that's where this project creator is useful. Right. I would still say they should come together as a single project and then we'll see where it goes later. And by single project you mean like all live in the same get hub or essentially the same get hub org. Okay. Yeah. All right I think we are up to time. I think because we have several left it means that next time we do a private meeting we will go through what's left on the spreadsheet. So apologies to anyone we haven't got to two weeks time I think is it two weeks. Weeks time I will check to make sure there's nothing else on the calendars and I will put that in the follow up and also as a note on the spreadsheet. So, thanks. Great. Bye. Bye. Thank you bye bye.