 Okay, recording has started. Go ahead. All right. So one of the points you had was a GitLab API version for the project, right? GitLab 4j, GitLab 4j version. Great. Okay. And so let's look at, so what I saw was this declaration. That's using the Jenkins API wrapper plugin. And it's 5.2.0. It will remain. And I think that's actually the one we want until the wrapper is ready to do 6.0. That was that was a piece that that I was ultimately I may be able to agree that we will eventually get to 6.0 but for right now. We'll have to use 5.2 consider right. That was my assumption anyway now others may correct me if I'm wrong but I thought so when I did my initial experiment. I just use this wrapper plugin and I was delighted it worked the way I'd hope when I wrote an automated test to connect to the API. So you're right on this point that the problem is the PR that I made is for 6.0.0. So when the release will be cut then we'll be using the 6.0.0 version. So the GitLab API has to be updated to 6.0.0. So that's what I was talking about. Good. All right. Well, and that's so the GitLab API plugin will need to adapt. Are you okay if I'm typing in your plan. Sorry. No worries. Okay. I gave you the editor's access. Okay. Why are we using that new version though. Go ahead and harsh you can describe it. I added the commit build status in the through my PR in the GitLab 4j because we were not having that and we required that for changing the commit status. So that's why in the version 5.2.0 we don't have that we need that actually. That's why. Okay, so you're going to need. You're going to need GitLab 4j to be released with that change and for it to be adopted in the wrapper plugin and then eventually in the GitLab plugin. Okay, that's right. Well, now, but in terms of timing. Harsh I assume you can you can do your development with the current version with 5.2.0 and and make good progress the the API you need is not there yet, or that enumeration is not there yet but you can still proceed with 5.2.0. Is that correct. Yep, I can. Okay, good. We'll be waiting for the release to cut and after that I can migrate it. It's easy. So it's not much of an issue for me. As a has a release candidate been published from GitLab 4j are you still waiting for them to publish something that contains your changes. Yeah, it has not been published I have been bring the maintain it over there and I hope for the response. It will take time I know for sure. Okay, as soon as, as soon as they publish something, then you could start adapting it from Jenkins side and the wrapper plugin, but if it takes them more than a week or so. And there's an alternative which is for you to deploy a snapshot build to the Jenkins Artifactory server. And I would, I would want to check up on this the next time we meet to see if there's any progress or not. So there's no progress upstream. I can run Maven deploy with some special arguments, which I would need to look up to deploy GitLab 4j against our Jenkins Artifactory in a special snapshot area. And then what you could do from there is file a draft pull request in the wrapper plugin to consume that snapshot. And then that that draft pull request would generate an incremental build because all Jenkins plugin pull requests create incremental builds and then you could consume that incremental build from the GitLab plugin. So, there's, there's a way for there's a way for us to do this internally, but it's a lot more complicated. So if we can just wait a week and if upstream is responsive, that would be the easier method. If they aren't responsive, then we shouldn't block ourselves based on that. That was a great idea. No, no, but harsh in terms of the timing. I thought that there were an awful lot of other things that you could be doing that don't require that API addition you did for 6.0. I mean, even bozzles. I love bozzles energy that's great in terms of a week or two but my assumption was you could go as much as a month and still make really good progress without requiring the 6.0 release of GitLab 4j API. Yeah, that's what I plan to do. I mean, I may, we may have other things to do, but if we don't start testing this sooner rather than later, we might not discover problems with it either. So, that's a really great point. That's a really great point. It would be, it would be unfortunate if we waited a month for the upstream to release this and then discovered that we had the problem with it and needed a second release. So, the sooner we start using basically the sooner we start eating our own dog food, the more feedback we're going to get. So, yeah, I mean, we could we could wait a month but I personally not wait that long, but either way, it's fine with me. Okay, I've got a question. Yeah, go ahead. It's like, um, can harsh do it or do we have to do a train for a snapshot. So, were you asking who can publish snapshots. Yeah, yeah, should we do it to anyone who can, anyone who can do releases of Jenkins plugins can publish to actually know. Now that I think about it. All you need is a login to Artifactory, which I think everyone has. But if you have an LDAP account, which everyone with anyone with a Jenkins.io LDAP account can log into Artifactory and after you log in for the first time, you'll have an Artifactory account. Once you have an Artifactory account, you can publish to the snapshots area. You don't need any specific permissions in the repository permissions updater. It's, we essentially give anyone in the project permissions to publish to that snapshot area and it's safe because it's not consumed by any production builds. In fact, there's a lot of Maven logic to prevent snapshots from ever being used in a production build. So that's why everyone has access to it. Okay, I see. That's about the test that you were talking about, you can actually skip that the commit status. I added one commit status called skipped, and we can skip that test instead that's a very small test that I will be adding. So, I don't think so it will be that much of a major issue because it's the small part of a code. It's not that big. Great. Well, and I think, I think I understand Basel's point, it was a point that I had missed it's the sooner we're on to what you're what you believe your final destination or near final destination is a version six to know the better it will be for for everybody. So that that also has the benefit that you become the, the leading tester, the leading check that 6.0 could be consumed by other things like the get lab branch source or the get that get lab logo plug in so so it's it's a benefit to the project as a whole. If you're if you're on 6.0 sooner rather than later. Great. Okay. So, let's get to the second thing that I wanted to wanted to discuss. So, best suggested that we implement the end to end implementation of the get a plugin first. But when I tried doing that the plugin is the plugins code is so tightly bounded that I cannot let it lose like, when I try to implement the webhook listener, then I have to change all others other than push also like more request also. It is, it is getting into the complete migration so I cannot really establish an end to end connection, like Basil said so we have to get into some other approach for this that I discussed with Chris. Like, how are you. That is your opinion on that because we wanted to like we want what we wanted to do is we wanted to first implement the to migrate from the rest easy to get left for Jay, while taking the webhook thing implemented as it is. Now when the webhook thing is implemented as it is, and we are using get left for Jay for the calls, the plugins, the plugins should still work. Now after that as a second milestone what we could buy what we wanted to do was, we wanted to remove the webhook thing and implement the webhook thing. Now again the plugin should work and after that we wanted to implement the proxy thing. So that's how we and I and Chris discussed. So what's your opinion on that. That's just a question about the order of operations of which, which parts of the project we implement first. And what were the, what were the three parts again. So first we will, first we will migrate the resource calls from rest easy to get left for Jay. Yeah, and we will migrate the webhook thing and then after that we'll add the proxy settings. Yeah, I mean that that sounds fine to me. The proxy thing should definitely be at the very end because that's not needed to test the other. I chose this order because I could test this in order like once the get left for the resource calls are being used. I don't need to tend to account with the webhook thing and I can test all of that after then, after migrating the webhook thing also I can test the complete plugin after, after migrating the proxy settings also I can test the complete plugin. So it will be in a correct order. So that's why I chose this order. So I captured the what you said correctly harsh it was migrate the resource calls, then migrate the webhook calls. Yeah. Okay, and I like that. Okay. And then migrate the proxy set proxy calls or proxy operations proxy to get lab for Jay. Those two things we won't be implementing the proxy thing I'll remove them. And at the last I'll implement the proxy thing and we can test the complete plugin after that also. Because if I implement the end to end thing it is very hard to test it. It's really hard. I cannot test that. So I'm trying to test it step by step. So any issues with this thing. None, none for me that sounds great and I think I heard felt Basel said the same thing and since you and Chris had discussed it this sounds like a great approach. Yeah, so the next thing I would like to discuss is how are you going to review my code so how how can I make sure that you are able to review my code easily because there are there are a lot of changes. How are you going to do that. So my usual technique is I run the code. Look at it in a debugger watch that the break points in the debugger that I think should be hit our hit. And then I tested interactively. Now I'm not sure any of those things are dependent on how how you submit the poll request did I did I answer your question hard. Yeah, I thought you'll be checking the code line by line if I'm writing if I'm importing things like I understood what you're trying to do. Fine. Well, so, so others may have a different approach. So, Mark likes to run the code to read the code. Run the code in debugger. That's a great way of reviewing actually run the tests in a debugger with break points. And I'm happy to learn from other people's techniques. Anything else to share. So you're, you're, have you posted anything so far? Or is it just what you're planning to do? I'm planning to make my first PR soon. Okay. And that's going to be the, that's going to be the mega draft, right. So I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to do that. I'm going to make my first PR soon. Okay. And that's going to be the, that's going to be the mega draft, right? I mean, we discussed last time that. Yeah. So I forgot discussing about that. It's going to be a work in progress because we want to use the Jenkins CI CD tests that are already implemented in the pull request. If we make a draft pull request, we won't be able to use the CI CD thing. Pull draft pull requests get evaluated in CI. Yeah. Yeah. Yeah. Yeah. Yeah. Yes, they run when you submit a draft pull request, it still runs full CI. Oh, that's great. I mean, Go ahead, Basel. It's probably it's CI is probably the tests are probably going to fail. And need. Yeah. Adapting. So even, even if the code that's in the main branch is completely correct. Yeah. I mean, I think the main thing that I would want to see as a reviewer is Some sort of written. Guidance on how to, how to read the change. Like what, what parts. This is going to be a huge pull request. Yeah. And I, you know, I assume that at the. By the, by the end of the project, we'll find things that we could split off and merge earlier. But in the mean, you know, in the meantime, you're. You have in your mind. Very clear understanding of what you were doing. But for someone else. Who has not been deep in your mind for the last week or so. It's going to be, it's going to be hard to figure out kind of how to read very long change. So if you can, if you can talk about. If you can talk about the major parts of the. The major parts of the change, for example. You know, start by reading this file, which is the first part of the execution path. And then when you're done reading that read this second file, which is this, you know, the next thing. Because, you know what, when you're scrolling through like. Dozens of files and hundreds of lines. Just even just knowing the order of operations to read the code changes is a huge help. But yeah, but even beyond that. The, you know, the reasoning behind each one, the more detailed, the better. But yeah, I do this very often when I. When I submit large changes for others to review, I'll write them down. And basically just tell them, you know, what order to read everything and for it to make sense chronologically at least. What can I do is I can comment out the understanding that's why am I doing this instead of what am I doing? Like when I'm, when I'm going to migrate from the STC to get leverage, I can comment out that refer these links. This is how I am I doing. This is what I'm doing. This is where the method is being called. This is where the method is being returned. So I think this would help you guys a lot. And that's a really great idea. Because yeah, I understand it. It is difficult to actually understand the code with. I think the code was easy. It's actually. Understanding was difficult. Yeah. It's always harder than writing it. And extrapolating reasoning after the fact is always more difficult than coming up with the reasoning after noticing a problem. Yeah. So any comments on this? Chris. No. Mark. No, that's. That sounds great to me. I've read it. I've liked reading. There will be times when Basel will even go so far on some of the things that he submitted to go into the poll request itself. And insert comments. Of his own into the, into the poll request using the GitHub. GitHub interface, making a comment about this thing or that thing. And again, what's that doing? That's helping the rest of us as we're trying to comprehend this change. He's giving us guidance on. Hey, this changes and you should think about this first and then this, or I was thinking about this when I wrote that. And that's why I did it this way. Yeah. So it's going to be a ready discussion. Right. Yeah. Now, now in terms of whether or not the poll request should be draft. I don't, for me, I typically treat draft poll requests as though probably I shouldn't review, but I'm perfectly okay if we agree as a group that we're going to review your draft poll requests and you're okay with that. I assume you're okay. That we can give you review comments anytime and you, you won't be irritated or frustrated at us giving review comments. No, it's not a problem. Okay. Well, if there are, if there are pieces that are intentionally. Emitted or incomplete. You could just mention that in the notes and say, you know, don't bother reviewing this file. I haven't even. I haven't even really thought about it yet. And it's income. You know, so. There's, there's nothing wrong with. Posting incomplete change, but it would be good to point that out. So we don't spend too much time scrutinizing the parts that are incomplete. Yeah, I'll have to do some minor changes just to make the code compile. So I'll write it. There are some stupid changes that I'll have to do. Okay. So anything else? That's all that I have. So one of the action items that I also have is to create a UML, UML schematic diagram for the web hook implementation that Chris asked. So I'll have a session with Priam. On Saturday, when he'll be teaching me about this because I don't really know UML syntax and stuff. So I'll also be adding it in the project plan. For easier understanding. Great. Thank you. Yeah. Now I am not a, I am not a unified. I'm not a unified. I'm not a unified. I'm not a unified. I'm not a unified. I am not a, I'm not a unified modeling language users. So I apologize if, if I fail to use the correct terminology, et cetera, but the, the act of diagramming and the effort to draw those pictures. Oftentimes is the thing that helps you think most clearly about what you're trying to do. So it's not that the diagram is so important. It's rather that you're doing the effort to get to the diagram is the thing that's so valuable. Yeah. That's what I agree. So the next thing I don't think for anything else. Like I'll be making the PR soon I'm working on the test. And I have to debug it also and see it interactively that it works. But I don't know when will I be submitting the PR, but it will be soon. Great. Great. Okay. So. For the first milestone, not the complete migration for the first milestone. Of course, of course, just. And I'm, I'm less concerned about milestones and more to be sure that you get. That you're rolling and that we can see how you're progressing and that we can help you as needed. Yep. We do we want to create a project. Range for this to. Get the basically to get the prototype. To get to get the prototype in a state where. It can be, you know, tested by other people easily. Or do we want to use. Do we want to use a regular pull request to do this? I don't, I don't really have a strong preference. Good question. So harsh. What. What Basel is pointing to is that. We could, if we were to create a separate branch. We could then have you submit pull request to that separate branch. And then the C.I. will build that separate branch independent of master. So we're not disturbing the master branch. And, and we've then got incremental artifacts. That we can then you run for. Run tests against. We can experiment with. It gives us a staging area before emerge to master. Yeah. Sorry. No, please, please. So I asked about this in the first meeting again, like how will be the branching pattern? Remember, I asked this. So this is the same question. So you were talking about something that. Yeah, it's not your local branch. Oh, it's like the branch on like on get on on the. Yeah, that's what I was talking about at that time also on the GitHub. It's a bit different. We have to do it for you. You cannot do yourself. Oh, okay. Yeah, I mean, I think the advantage to doing. Project branches that you can then open up multiple. Pull requests into that project branch to describe different. Different work that you're doing that may not be ready to commit to the main branch. If we don't have a project branch, then. You're single mega pull request would basically become the project branch and any changes that you make. Would have to be discussed in a single pull request rather than in multiple pull requests. So. Yeah, and I, yeah, when I wrote that, that the pull request becomes the project branch. I'm using project branch in. In scare. Right, right, exactly. Yeah, so I don't have a strong preference here, but I think if I might. I might like having a project branch so that. You can basically open up multiple separate changes and we could review them separately. And you know, the only, the only rules we would really have for the project branch. Or, you know, just that it compiles. You know, we wouldn't, we wouldn't need, you know, any. Guarantees like we do on the main branch that it actually works or that it's releasable or anything like that, or that the tests are passing. You just say simply, you know, we could even, we could even turn off the tests on the project branch by setting, you know, maven configuration so that it doesn't even bother running them. You know, and then that, you know, that project branch with the tests disabled can be, you know, something that we slowly get to a state where it works, not just compiles, but actually works, and that can be done in separate pull requests as you, you know, because what I'm, what I'm afraid of is that having a single large pull request will become too unwieldy by unwieldy. I just mean that there's too many separate conversations going on and become too difficult to keep track of different areas of work like this webhook stuff or this resource call stuff. So, I guess I have a slight preference for a project branch that has the tests disabled and smaller pull requests to that. But I'm willing to do a different style as well. Well, I agree with this. This is actually quite great. Any objections? Oh, none for me. That sounds fine. Can we keep the task or not to keep the tasks? Which one is your preference? We can keep the branch actually. That would be great. I mean, I mean the tasks. The test. Do you want the task? I'll have to see. Yeah, the test, the test can be helpful, but I'm sure it's going to fail. I'm almost, I'm almost sure it's going to fail. Yeah, I mean, I think we could, we could re-enable the tests on the project branch after the main code is working into end. Yeah. And at that point, when we see, when we see failures, we'll know for sure that they're because of test issues rather than because of production issues. But right now we wouldn't know either way, but we would suspect that the tests, test issues and production issues. So first we'll disable the tests and after that, we can enable the tests after the things are kind of finalized. So yeah, that's, that's a very good approach. Yeah. Yeah, I would just whoever creates the project branch. If they could, if they could also push a, push a first commit to it, to turn off the tests. Oh, I could even do that if needed. I think that, you know, that would. You could just add, you know, skip tests as a Maven property. Okay. And that would, that would mean that our standard for integration to this branch is just that it compiles. So pretty low standard, but at the same time. That would allow us to file smaller pull requests against that project branch. And as long as they compile, you know, we could approve them and go through a relatively normal code review process. Rather than just having this very long-lived mega pull request. Okay. I'll do that. It's okay with you, Mark. Yes, that'd be great. Thanks Chris for your willingness. So I assume one of the, one of the responsibilities we'll have during this project then is when changes merge to the master branch, we want to keep the project branch current with it. So we'll merge outward to the project branch. And harsh. I assume you do that. Or Chris or I can do that. Anybody who's a maintainer can do it, but you can even submit pull request proposing it. I could create a GitHub action to automatically create PRS to do merges. Okay. Even better. I didn't realize there was such a thing. That sounds really elegant. Yeah. Anything else. I don't have anything else now. Okay. I wanted to take a minute or if there are no other topics, I wanted to double check our mentor checklist just to be sure that we've not missed something with you harsh. Are there other things on you on your list that. We need to discuss before we look at that checklist. No, that's what I wanted to ask. Okay. Great. So mentors to discuss about the refinement of the project plan, finalizing deadlines and milestones. Okay. If you've done that, everyone okay with me checking this one is done. Okay. Good. And then. Office hours. Meeting weekly, which we're doing. Okay. Yes, we're reading. I feel like we're okay then the checklist looks good to me. Okay. All right. Thanks. I think that's it. If there are no other topics, I'll stop the recording and we'll, I'll post the copy of the recording. In 24 hours or less.