 all yours. Okay. So I'm sharing my screen. So for today's meeting, the first, the first point of discussion is authentication with git to chooser. So, so I've been working. So I was on on priority. I was working on completing the GitHub Brand Source Plugin extension implementation, but that is currently blocked on tests. I, I think Liam is busy right now. So we could not have a conversation after the last, the previous thing we've had. So I, I, I tried. So the issue I have there is that I'm not able to use a mob GitHub server API server to stop data and mock calls so that I can write test cases. So I have written the test cases and I am using the already they have a, they have a class, a utility class, which provides a mock server for such purposes. But despite extending them, my, the API, the API that I've created for the extension, they are still trying to contact the GitHub server API. So that's creating an issue. And I'm not able to figure out why that is happening. So I would need his help for that. So, so meanwhile, I started working on how I could do the same thing for GitLab. And I have created the extension. And while testing it, I've, I've seen some issues which might be, might be of concern for us. The first is for, for GitLab, so for GitHub, sending the repository URL. If you're not talking about credentials right now, just a method to get the size URL was enough for us sending that information was enough for us to get the size of the repository. But in case of GitLab, so for GitLab, there is a concept of a GitLab server. And we need to configure that a user need to configure that before trying to open a create a GitLab project, organization for project or multi branch project. So the problem with, so there is no problem with configuring it, we, we don't have. So the problem with this configuration is that GitLab branch source plugin is expecting that we know the server name. Instead of the server URL to instantiate the API instance. So to create an API, it would expect the server name instead of the server URL, which I could not understand first, because I thought that there should be a way since internally, it would use the server URL to connect. Why would it not expose the server, a method to provide us a method where we could just enter the service URL and connect to the API, but I could not find one. So that is something of a concern for us because the Git plugin would not be aware of the server name for GitLab for this configuration. And so that's, that's something we have to think about also with GitLab, what I've seen in terms of now, let's come to authentication. With authentication, we don't have to worry in GitLab, they do that themselves. So what happens is if we provide the server name, if you can see in the configuration here, let me zoom a little bit, the user would add the credentials and a secret token. So it requires a personal token, a GitLab personal token. So all of that the user would enter here and all of that is managed by GitLab itself. We just need to provide it the server name, it will look and scan for those credentials. So that's a great thing in terms of sending when we were confused how to send the credentials. And then I went back to GitHub Brand Source plugin to see if, since GitHub Brand Source plugin maybe not, we don't have to configure, I think in the same way, create a configuration in the same way, we would have a user stored configuration for the project in the GitHub Brand Source plugin as well. So the GitHub Brand Source plugin would have the credentials, it should, it may have a method where it would not need the credentials to create an API instance. I haven't found one. I will look more and I'll ask Liam if there's a way. But since it's possible in GitLab, I'm just wondering if it's, if it's something which is also possible with GitHub Brand Source plugin or not. I was checking but I could not find the method. With the name thing, what I want to ask is that since this is a global configurations page, how can we access this if we were, if we were to send the name instead of the URL? How would we access this information? Is this stored? So this is, this is captured by the descriptor class of the particular plugin or is this stored in the environment variable? Well, one second though, like, are you thinking the secret token is going to manage how you would talk to the API? Because that's just for web folks. No, no, Justin, I'm talking about, so the GitHub, so the GitLab Brand Source plugin expects that we know the server name of the GitLab server when we're asking for any details. So, so we would know the server URL that we can extract from the repository URL. But the server name is something which is ideal, which is unique for this configuration used by the plugin. So, yes, yes, Mark. I think we should take advantage of a previous mentor and ask Parichet Barpanda. He wrote this code, because I don't know how you're going to do it. It's got me completely perplexed. It's that I agree with your observation. The URL to a repository is clearly the way to identify a repository. Why should I have to know a display name that a user assigned to one of potentially many GitLab servers that are connected to this Jenkins instance? But Parichet probably will give very good reasons why. And I just don't know how you're going to fit it into the API, because a GitLab server name probably isn't needed for Giddy or for BitBucket or for GitHub. So, yeah, no, it is. Oh, is it? Yeah, because you can have a personal server. That's what that's for. You can run a server on your in your enterprise or at your house. Same thing for GitHub. Right, right. And no dispute that you can run it. And BitBucket. Right, no dispute that I could have multiple Giddy servers and multiple, multiple of any server, right? Absolutely. It's that even if I have multiple of them, the server, the URL to the repository is still the unique identifier for the repository. And so needing to know the name of now, maybe there is such a concept in GitHub as well, and we should gather it everywhere. I haven't, let me look at my installation. I don't think that I've defined one. Yeah, let me look at one, too. But I mean, I think the GitHub branch source plugin should know this for that item, though. It should have a Giddy name as well. Well, it already knows which server these are selected for that pipeline. Like you have to configure that. Like that particular multi-branch project has to be configured with the server. So you've got a hook there. I was a mentor on the GitLab branch source plugin. Oh, that's right. That's right. We have your benefit as well. You were mentoring Potty J. I didn't write the code, though. No, but you were going to thank Potty J. That's right. Yeah, yeah. But Potty J rocked that. So like, and I had some other stuff going on personally. So there may be things that we do need to hit him up on. So I'm totally. OK, so that was a point of information. Not a let's not talk about it. Well, and and I see that GitHub servers also have a display name. Yeah. So so and it's exactly for that because you might want to connect GitHub and then you might also want to connect something else. But your multi-branch. Your multi-branch project needs to be set up with one of those endpoints. And that helps with the scanning and all that kind of stuff. Because Jenkins needs to do like org scanning to see if it's got like a new Jenkins file, if it's got any changes, if it even qualifies, if it even has a Jenkins file or a config driven pipeline. Marker file. Sorry, I'm marketing my own little plug in. But that's kind of why does that kind of make sense? Yes. My question is that if I have the repository URL, even if it's a private server and the user has entered the repository URL, that should be enough to get me that information, right? Why would I need to know the server name for for to to get the size of the repository if I have the repository URL? So the branch source plugins have those as two separate pieces of information. You don't just plug in the repo URL. What you do is you plug in which GitHub server you want and then what owner that is. If you've got like if you're trying to do it on an org level, you do what owner it is. And then it's going to scan everything underneath that org or like a GitHub org, find all the repositories that qualify. Create projects for those and then those each have things. Actually, maybe in under the projects, there might be a little bit more semblance of that, but that's not something you can figure at the at the lower level repository level. So isn't isn't the challenge then for for Rishabh is that in the context where he's running, how does how does he communicate back to GitLab or how does he determine which API endpoint or which which GitLab name is being used because I assume you're you've got an item context, right, Rishabh. There is an item context and that thing could therefore be part of a job or is a job that is running inside of a multi branch pipeline or inside of an organization folder. But now you need you need information to pass to the GitLab server, which is somehow all the way up at that organization folder, right, that you need to know which GitLab API endpoint they should use. And one way of identifying the API endpoint is by this display name. So my my sense, my sense still is it justifies a conversation with Parichet. Yeah, I did ask him this question, I think, and I'll back on the Gitter channel. But I think we if we can have a conversation with him and that would be great. Well, and it may be that we need to do some if if Parichet doesn't respond by say Monday, we can probably ask questions to the maintainer of the GITI plugin, Stephen Connolly, or to the maintainers of the SCM API, like Jesse Glick and Devin Nussbaum and Liam Newman. Because I think each of those people at Devin, maybe not, but Jesse Glick certainly knows the SCM API and Stephen created the SCM API. OK, so. So I think what's interesting is that the GitHub plug in the GitHub plug in is what has your repository URL in a GitHub branch source. Yes, and if you go to that repository thing, that's where you have that. But I guess you're trying to find out where how to get the connection back and forth. So what I'm not able to understand is that how am I how am I able to do this in GitHub branch source plug in without even checking or knowing about the server name? I wonder if this needs to be done in the GitHub plug in. OK, the GitHub plug in which wraps on the Java API is for GitHub. Yeah. Well, so the GitHub, remember, the GitHub branch source plug in depends on the GitHub plug in, which depends on the get plug in. And then if you look at a repo view, you don't see like that project doesn't have any awareness that it's part of a branch source. It has a GitHub. Well, it does know that. Sorry, as a branch sources portion, you can kind of see some of this stuff in the UI, like how plugins work together. Because they'll have their own like jelly labels and stuff like that. It's kind of interesting, but anyways, you can tell that the GitHub is a GitHub configuration that has credentials. It has the repository, HTTPS URL. And then that is what is invoking get plug in, I think. For GitHub, I don't know, we can look at GitHub, too, but I can I can also try and see if I can find some time to look into this a little deeper, too. But yeah, some of those other folks might know it off the top of their head. I'm a little rusty on some of it, so. So I think from my side, I have why I haven't explored this idea that I've always tried to, when I'm interactively testing the extensions, I've always done it with just installing these modified plugins, the GitHub or the GitLab plugin, not configuring a multi-branch project, just running a freestyle job for Git plugin and seeing if those extensions are able to provide the size. So that is why I haven't completely, I would say, ignored that site that if we have a multi-branch source, let's say a GitHub organization project or a GitLab organization project, in that case, how, so in GitLab, I was forced to go to the global configurations and add a server, add a server name, add those details. In GitHub, I did not have to do anything. I, my plugin was able to adjust the repository URL, was able to communicate the size to me. So when I started to explain GitLab, that is when I understood, okay, there's, there's a layer which I did not look at. But isn't, isn't that hinting that it may be that some of the branch source implementations may not be usable outside of a branch source context? So this, the GitLab condition you see may hint that, okay, the GitHub plugin is structured so that we can ask this question. But the GitLab plugin is not. And maybe it's time to say, ask the question to Padache and then say, I'm going to go try another one or, or focus elsewhere just because it may be that, that the GitLab plugin isn't ready to answer the question that we want to ask in the context where we want to ask it. I hadn't even thought of the, the, the, you described it very, very well, a freestyle project doesn't have an organization folder or a multi-branch context to, to be able to provide. It's very good insight. Yes, Mark. So, so I think since, I think we have what two weeks now to, if you want to release this, like these features with the new version. So, so I don't want to be blogged. I, I think I can explore from my side by creating a multi-branch project. And then, so the best way for me personally is I debug, I try to debug the local instance by attaching a Maven debugger. So if I'm able to understand how the interactions are working there. So I'll, I'll try that personally, but I, I think I've asked Parichay if he's able to respond, if we are to get that answer for the weekend, it's okay. So, so my question is that should I move on to the GITI brand source plugin? Either GITI or Bitbucket, no objections from me. Bitbucket is probably more popular than, than GITI. It's, it's on the flip side probably also much has a much longer history and many more authors in it. So it'll be more complicated than the GITI plugin. But, but I, I, I just remember that Fran Francisco told me that the Bitbucket brand source plugin is not, is abandoned right now. I think that's the right term for it. Then, then that's another good reason to you to consider GITI instead. Yes, that's, that's what Fran told me. And, and it's this thing I forgot actually throughout this discussion. I, I remember that is it absolutely necessary for us to look at the brand source plugins to get this information for an example, right now, we're seeing that the Github plugin might be able to provide us this information as well. So, so is it for, so for the other plugins as well, do we absolutely need a brand source plugin to get this, because when I was thinking about GIT2 chooser and getting the size, I was not thinking about the, the, the layers upon which these brand source plugins depend. So now, as I've seen the code, I understand that these brand source plugins are implementing another plugin, which wraps around the Java APIs with for the REST APIs, it says the Java code for the REST APIs for maybe GIT lab or for Github, we have the Github plugin. I've seen that. So do we need the brand source plugin? Because we just need, we need the size. We're, we're looking at brand source because I just, I, I, I did not know that we could do the same thing with the Github plugin. But if we can do the same thing with the Github plugin, why would we need to ask that question to the brand source plugin? Or. Yeah. So this is actually clearing up some cobwebs in my mind. Um, so what you're doing is actually a great test. This freestyle project approach is actually the proper way because you actually don't care about multi a branch projects because that already gives you the cash, right? Um, so between what you've already done, like the great work you've already done, and then that, like, I think your test is going well in terms of like freestyle project. Um, a branch source plugin generally just sets up a project for you and sets up a branch source with that provider's plugin stuff. So I think you're going to be able to accomplish this in and, and I, I do recall that in the GitLab project, we were also trying to kind of take advantage of a lot of the success that the Github branch source plugin and Github plugin suite in general was doing. So I think that pattern is going to be fairly consistent across the way. And I do remember that we, I think, Parichet had worked with, um, Jesse and some other folks and probably Stephen, all, yeah, I think Stephen and Jesse on some of those. So yeah, you might look at Github and GitLab plugins to see what you can get there, what you can get there. So, so I think the direct answer to your question, Rishabh, is no, we don't need a branch source. What we need is some, some component, any component that implements a REST API to a Git provider could potentially be an extension implementer in this case. It just happens that the branch sources always have to do a REST API implementation and therefore they are a likely candidate to have a REST API implementation. So, but, but you're absolutely right. If there's a, if there's a plugin that provides an API to a provider that would answer the question about size, then that plugin is a candidate to implement this extension. Yes. And, okay, so I think, um, I will, and, um, what I also want to ask is that, so it's not necessary that each branch source plugin would have a plugin depending on a plugin which is implementing the APIs. It, it may be possible that those APIs are implemented within the branch source plugin. That is exactly the pattern that the GIDI plugin uses. It's all inside the plugin called GIDI and the GIDI plugin is a branch source plugin and it, it implements. So now that, but it's also a branch source plugin. Exactly. Yeah. But, but it's different for GitHub branch source, right? Where I believe GitHub branch source depends on another plugin that provides a GitHub API. Yes. So, so the, there are distinct differences and I, I don't know on the BitBucket plugin or the GitLab plugin, but I assume some, some variant of that exists there. Yeah. The GitHub plugin is definitely that way. I'm not sure about BitBucket. So Justin, when you say that way, GitLab plugin relies on a separate API plugin or it's, it's got a bundle inside. So there was already a GitLab plugin itself. There was, there were several plugins for GitLab and this was also like cleaning up a little bit of that, but there is a, let me double check, but GIDI.com, GIDI, GitLab plugin, I think is the, is the implementer and so the GitLab branch source plugin sets up GitLab. Okay. So there is a GitLab API plugin. Okay. Got it. Uh, there may not be an API plugin, but there's a GitLab plugin itself, which made you like, sometimes they split those out too. Okay. But, uh, yeah, there's a GitLab plugin too, which you should definitely take a look at that. And that has a lot of information in it. In the reading and stuff. Uh, I, I, I will look at this and, um, I think the summary is, I think you're going to see this pattern, uh, across the branch source plugins, across, across things that also have a branch source plugin, or maybe have that branch source stuff embedded in their plugin. And you'll probably be able to take advantage of the same pattern across because those APIs are all kind of snipping off of SEM API also. Hmm. I had to do that myself in my own place. Okay. So, uh, okay, I'll do that. So I think the next, the next concern for me is I want to discuss was, um, we have a similar technique. I, we have discussed that. Because of server name, we've discussed it. I, I had one more thing in my mind. I don't know what to remember. Oh, yes. So with GitLab, one more thing that I've seen is that, so, um, GitLab for GitLab repository, if we get up, we have repositories and in GitLab, I think the equivalent is a project. And, um, so for a project, we have, uh, the code base in it. And, uh, and I think the CI CD is, it has multiple things. It's, it's a broader definition and repositories. So, so to get the size of the, of, of the code base of the objects we have, it, it, uh, it uses a separate extension of the API, which is called, which basically adds a statistics, um, boolean to it, the, the whole API to get that information. And what I'm seeing, uh, so we have roles in the GitLab, right? For permissions, we have roles. We have the owner, we have developed developers. I, I, I think I have opened it. We have guest reporter, developer, maintainer and owner. So one worrying thing that I've seen is that to see those statistics, the, the user, which is trying to, um, get that information that is the size of the repository, the user should be the owner of that repository, which then seems, uh, I think we cannot do anything about it. If GitLab has decided that, but then it, um, narrows down our scope. I think in a, in a huge way, because our, our developer, developer maintain a reporter or at any less, we'll not be able to get that information, but for a certain type of role, which, which, which is, I think is an issue. So I, I did check, uh, if, if this is true or not, you project statistics. So here it does say that the developer, the maintainer and the owner, all, uh, those three can see this, but strangely enough, when I go to, um, the project API, which is, uh, the GitLab Danso's, um, um, I think this is the GitLab plugin only where the instances, the GitLab API instance is being created using, uh, this, um, class. So there it says that to get a specific project, which is owned by the authenticated user, that is how we can get the project statistics. And, uh, this is how we can get the size. So, um, so with GitLab, I haven't tested, I wrote the extension. I, um, and I could not test it, test it in the sense that I did not, uh, put it in a local instance, I did put it in a local instance, but I was not able to get the size. I was having some issues with it. So, um, I, I think I need to make sure that, make sure that, um, that we may not be able to, and not everyone may be able to get the size of, uh, the project or the repository. So, and if it's, if it's just the owner, then that might be, that might limit our use case, but it, I, I don't think there is something we can do about it. Yeah, that might be something that you need to, and documenting or something like that, um, if it's, if it's a specific permission that needs to be set up for that token that you wouldn't already get by just simply setting up a GitLab project. Hmm. Okay. Okay. Actually, uh, so to go back to the caching thing, if you have a branch source, no matter what you have a cache, right? Yes. So I guess that maybe doubles down on the fact that you should probably just use the GitHub or GitLab plugins rather than the branch source because then you set up a freestyle project with a GitHub setup or GitLab setup. That makes sense. That does make sense. We don't need those branch source plugins because if we have a branch source plugin, that means that we would have a branch source project, multi branch project. And if we have a multi branch project, then we have the cache. Um, Mark, is there, is there an issue with that statement? I'm just trying to understand how we communicate. How does the user, uh, who's, how does the user who defines a freestyle job tell us, tell, tell the plugin which GitLab server is being used behind this URL. And I think right now the answer is they don't. There's no facility for you. What do you mean they do? They actually, instead of setting up a Git project, you set up a GitLab project. You just, you just described a condition which is multi branch or organization folder, I think. I can't define a freestyle project that uses GitLab as an SCM as far as I know. I've never seen it anyway. Let me just check. But I'm fairly certain you can set up a GitHub source. I've seen that we have Git or we have Subversion. Yeah, I don't think that I don't think those higher level providers implement at the freestyle project level. Oh, yeah, you're right. But, but so, so we're back to the, it may be that the only fallback for a freestyle user is if they're lucky. And they've got a job to find elsewhere that causes them to have the cash for that. Because we freestyle has no way to say I want to use this GitLab server or I want to use this. And I don't, it feels like that would be huge, a huge scope creep for me. If you said, ooh, I'm going to add that so that anytime you add a Git project, you need to also optionally choose or add Git as the immediate option to choose the higher level provider. That just that I, that's, that's an awful lot of addition in a spot where we're just trying to get a guess of how big the repository is. Yeah, I mean, I think what you're, what we started with, I think at the beginning is probably the best you can do is try and detect it from the descriptors. In the instance, and that also assumes that you have access to do that. Yes. Okay, so, okay, I think that's what I have to do right now. And the last thing I wanted to discuss with the release plan for what we, so how do we want to, so with the Git to choose PR, I think we mark up senior comments and I just have to fix the test, the test case which was failing on Windows. And so I think after that, what all do we need for the Git to choose it? Or maybe should, okay, we have to wait till we do not find a consolidated way to communicate with the extension part of it, I think, right, we will not be able to finalize Git to choose it until and unless we know that how are we going to exactly communicate with the extension, extensions across the plugins. So I think then the Git to choose it is blocked until as we, so I have to look at the GitHub plugin and the GitLab plugin, the API plugins first, I think. Well, although I, yes, Mark. You've got a working implementation for GitHub plugin right now, right? We've got something that, so for me, I think that's already an indication that we should press forward using that except that, okay, for now, GitLab, we don't know how GitLab will provide that information, but we do know how GitHub can provide it. That already addresses, I guess, 50% or more of the cases right there. GitHub is a dominant provider and therefore that will be, there will be a lot of people very happy with that. Okay, so in that case, if we're, so if you're looking, so we have the GitHub, GitHub branch source plugin implementation and once the test cases that problem is fixed, we would have that PR merged and once we have that, so I want to understand how would we do this? Would we merge GitToolChooser first or would we wait for the GitHub branch source plugin to do that so that we know that, okay, one, there is one plugin which is supporting the tool chooser, now we can merge it inside the Git plugin or it's not necessary for us. I think we could merge the GitToolChooser first and let others arrive as they can. Do you see any reason why we shouldn't do it that way? No, I don't. I think we might not be able to address all the use cases. For all the users, we might not be able to get the size, but at least we have something which might do. So we have the cache estimation at least. So I think we can do it, but I haven't, so I haven't added the instantiations. I haven't added the GitToolChooser at every point because I've always, I'm stuck the authentication part or the extension. So what I want to ask is do I, should I add that within this PR or first should we add GitToolChooser as a separate independent class within the Git plugin? And then we add GitToolChooser in a separate PR. We add the GitToolChooser at places where we would need to make the decision of recommending an implementation. I'm more prone personally to the second style of add it in the current PR so that you've got a testable PR and I can be testing it then after you've committed and others can test it. Unless that's objectionable to you, that would be great for me because the sooner we get it to testability, the better the better others can assist us. Okay, so, okay, so, so I have done, so I have instantiated the GitToolChooser in the Git SCM, the checkout step in this PR, the PR 937, which is a branch taken from the current GitToolChooser branch is it supports the unsupported command functionality to give a better recommendation in terms of JGIT. So I think I would add all of those in this PR and then we could merge it with GitToolChooser or I'm not sure how should I do this? Well, it looked, as I was reading 937, it looked like a super set of 931 or at least a parallel of 931. Would you be comfortable integrating all the changes that are in 931 into 937 so that we could merge 937? Yes, yes, yes. Effectively, 931 has been a great experiment, but so long as all of its content is in 937, you could close 931 and we could then focus our evaluation on 937. Yes, I can definitely do that. And I'll, okay, I'll do that. I'll merge all of the contents of 931, 937. If I remember right, there were more tests in 931 and I don't want to lose those tests, right? I would add those tests. Yes, we have more tests in 931. We don't have those in 937. So 937 was just to, I created it for just the unsupported command feature and I thought that we would merge it and then go forward. It's just create more confusion for me. And we could do that as well. It's whatever works for you, right? There's nothing sacred about a pull request. We can open and close them all we want. Yes. So I think the point is that we want a single PR where we have the workable get to choose it for the get back type. Right. Now, now you could, you could optionally take everything, take the things that you've learned from 937 and pull them into 931, whichever one you feel is it just, as I was reviewing the two of them last night, I saw common code between them and thought, ah, he's been working one off the other. That's great. I assume we merge one of the two and you get to pick which one is better for you. Okay. I think since 931 has the latest design changes, 937 doesn't. So I would copy all the additions of 937 to 931. Yeah. Yeah. And I'll do that. You might be able to just rebase too, if you're, but yeah, it works for you. That's the best answer. There are all sorts of get power tools to help you reach up. There's cherry pick, there's rebase. There are all sorts of great things that and, and every one of those could be a terror cause you terrible wounds that are nearly fatal to your repository. So yes, get is a great power tool. And there are times it would be happy to cut your foot off. Oh, it's just rainbows and unicorns. Right. It's all rainbows and unicorns. Absolutely. I think this is it then for us. For us to release the tool chooser, I, we, we need to merge this one single PR with the workable solution. And apparently I will be, I am working on looking on the extensions. And I think that's, that's it for now. And then I need a mark. We need to figure out a way to either profile the instance where you have a lot of jobs or we could, you were talking about adding a timestamp, which could get. So if profiling is not possible, then we could do it, but. Is can we do that? Can we profile those in your instance? You are welcome to attempt it. I am happy to give you full access. I have never tried to profile inside a Docker image that is running something as large as my, there are only 4,000 jobs on my, on my CI instance. And of those 4,000 jobs, there's a reason that the computer that hosts, it has 32 gigabytes of memory. And so, so I worry that, that the profiler may, may cause you surprises that you didn't really want to have to manage. Whereas timestamps reporting to a file, to the log file are, are pretty predictable. They are, they are certainly aren't as fine-grained or as accurate as, as profiling, but they can give us course enough for this kind of, these kind of assessment. Okay. So, okay. So I think that we can take that approach of time stamping. So we timestamp the builds, right? It puts a timestamp on each line in the, in the job output. Okay. Okay. So we can calculate the difference. Right. Right. So if when it's, when it starts the JGIT fetch, there will be a timestamp. The next step after the JGIT fetch should have a timestamp line as well. Okay. Okay. So I guess I would have to do that. Before get to choose it and after get to choose it to understand the differences. Right. Right. Or, or what we would do is create two parallel jobs that clone the same repository. One with. Chooser enabled and one with chooser disabled things like that. Yeah. Yeah. Okay. Okay. Thank you everyone. I, I think I'll, I'll contact for a chance. See, I have to contact him and for a chair, both. I'll see if I can get those extensions working. All right. And, and so let, let us know. It sounds like you decided 931 is likely your primary focus and you'll backport into 931. Is that correct? Yes. Yes. So I will, I will keep my, I will put my intense focus on 931. Assuming that you'll bring things from 937 into it. Yes. That is what I'm going to. Excellent. Thanks for job. Thank you everyone. Thanks. Thanks.