 Welcome, this is the GitLab plug-in modernization project. It's June 23, 2023. Thanks for attending. Topics I've got on the agenda, action item report, discuss recent poll requests, discuss the plan for the second milestone, discussing the recording for the midterm presentation that will happen in about 10 days, and then upcoming timeline and unavailable dates, including harsh schedule for university exams. What other topics need to be on the agenda? No, I think it covers it all. That's what we're going to discuss today. Okay, great. So first, the action item report, I had the task to test the latest development. I've got my environment configured so that I could test with the released version. I've still got to do the development version. So harsh, I hope to get to that. It's been a busy week. So that one stays open. Any other action items that anyone needs to report on? As these were there last time, I'm just going to go ahead and delete them so that we see we're making progress on action items. Like the first question that I would like to ask, like, did you guys refer to the previous project meet where I discussed the second milestone plan? I don't know that others have, I did not. So I think we want to look at that as part of what your view is of the second milestone. Like because I have changed a bit on that, like I was discussing. I think Chris should be knowing, but I don't know about Basil whether he has seen it or not because he will be quite unaware. Alan, why don't we take a look at it? Let's go ahead with that and let's use that as part of our discussion of the second milestone, if that's okay, Harsh. I think let's talk together. I can explain it in a brief because Basil will be easily able to understand. Like I'll have to, a bit of changes here and there because of the complications that we were having. So I'll be explaining that also. Like I was discussing it throughout the week with Chris. Like the stupid level of difficulty that I'm having is I'm not able to find compatible enums to match. That's how bad it is getting sometimes. So Harsh, is what I'm showing helping or do you want to share your screen? You want to share your screen, that's great. Maybe I'll be doing that. But before that, wait a minute. About the review of the first PR, like Basil said me to change the connection, the auto detection system that I designed. Like did I, which I made. So like, is there something critically wrong with that thing which I did? Like the, because Basil is saying me to reinvent it. Like how it was implemented previously. But is there something critically wrong? Because if I do that, then I'll have to do the interactive testing again. Like totally again, because it's the main thing of the first milestone, right? The connection. So yeah, my feedback was blocking. So I was requesting those changes. The most critically wrong thing was that it's violating the API contract with nullability. Yeah, that changed, but about you said to call the version three and version four built-in clients from the plugin itself instead of relying on the GitLab for J. Right. And the other part of my feedback was that the, there's three, there's basically three classes. There's the auto detecting class, the V3 class and the V4 class. And in the original implementation, the auto detecting class was delegating to the other two classes sequentially. And in this new implementation, the auto detecting class is duplicating the code from the other two classes. So my feedback was that it should work the same way as the original version did by not duplicating any code. And instead calling into the V3 class and the V4 class. Okay, so I did that. Maybe you can check it out when I show you the code, which I did other than this, like about removing those unnecessary, rest easy things. Yeah. Okay, fine. I'll do it. No problems. So let me share my screen. Ja, is it visible to you guys? It is, yes. Yes. So that's what you guys were talking about. Like this, this is the auto detecting it left client builder class. And what Basel said was like, where is this? Yeah, I'm calling the build client out of it, which will be using the version three and the version four of the GitLab client builder. Instead, what I was doing previously was I was directly using the GitLab 4js and iterating through its versions and trying to establish collection here in the auto editing GitLab client builder itself. Now, according to the previous implementation, we will be using the client builders, version three and the version four. So that's what Basel was trying to say. So I'll have to change it. And like, I'll have to test it interactively again, like the first milestone. So like it's a bummer, but no worries about the second milestone. Yeah. So what happened like last week was I was discussing about it, but let me show you what I was doing. Like, okay. So the GitLab, this is where the request and response, we get the request and response from the Jenkins. So what we do after this is we instantiate the webhook manager and the system hook manager, it's here itself, like an added listeners and the listener becomes the action resolver for both webhook manager and the system hook manager. Okay. And then once, like if you guys have any question, while I'm explaining, you can just stop me there. Okay, fine. So in the action, just so, wait a minute, yeah. So in the action resolver, instead of using the, instead of getting, instead of getting the post method also, we will be intercepting the GitLab for J in between to get the post method in the form of overriding the events method which are in the GitLab for J. So that's what we do. And I designed a fire webhook build action, like it will be firing the webhook action or the system hook action according to the event which it has received. And it just calls the build action. Like I didn't remove the build action at all. Like I just intercepted it in GitLab for J's methodology of abstracting away the post request in between so that we could access that. And just unfortunately, I don't really have that to show the difference which I showed in the previous one because I committed those changes, that's why. So once it gets called to the build action, according to what like, yeah, so here comes the important part actually. So according to the GitLab for J hierarchy, we have two parent classes of abstract event and abstract push event. So these guys like push event, tag push event and their respective system hook events also belong to the abstract push event class and the other events belong to the abstract event class. Now there is quite a difference between them. Like the abstract event implements the event interface also but the abstract push event does not implement the event interface. So what is going to happen was previously in the GitLab plugin, what we had was we, where is that webhook action? Okay, note this, webhook, webhook, yeah, I found it, okay. This webhook trigger handler, we were getting an event which was extending the webhook but now since we have events but we don't even have an event parent class so we cannot extend the event. So what I'm trying to do is, I am not extending anything here. Like this is where something like, I would like to ask whether it is a good approach or not because I cannot extend anything because we don't even have a parent event class and like extending abstract event or abstract push event is not feasible in this case. So what is your view on that? Well, I don't have a view because I don't, I haven't had enough time to think about this. So if you could write something up in the chat room, I can read it later today and think about it some more. Okay, so I'll write about this on the GitLab chat. Like you were not available on the GitLab channel. That's why you were kind of unaware about what was happening. Like a lot of mess was there due to this. But I'm just explaining it, like what I'm trying to do. If you write up a question that summarizes all of this, I'll read it later today. Yeah. Okay, I'll write it on the GitLab channel then. So, and Harsh, does that work given your schedule? It's already 10, 30 p.m. your time. Does it need to wait until tomorrow for you to actually write it when you're awake and fully ready to write? No, I can write in the night also. Like it's a lot of great. Super. I'll just explain. Yeah, someone was saying. Okay, so I should continue. So it does not extend any webhook. Like, and it's not also extending any event. So it's just a, like, it will just receive an event and this event can be anything. Like it can be abstract event or abstract push event. Now we will have subclasses according to this. Like I explained previously that push event, track push event, merge request event and all those events we'll be having. And we'll be having separate handlers, separate handlers constructors for them. Now in the abstract webhook trigger handler here, what was happening was we had to abstract away some methods that were there in this class because this event was not extending any event object. And because it was not extending any event object, we did not have any event methods. So I had to remove some of those methods and I implemented them in the respective handlers itself instead of the abstract webhook trigger handler. So that's what I did with it. When it goes to abstract, no, push hook trigger handler. Yeah, like ignore this abstract push event. Like I was doing something else and something else happened. Ignore this. Yeah, so we would require to handle it with respect to the event. Like it either receives the push event or tag push event and the code is quite redundant in this case because like it's the similar kind of event which I have to receive and act upon. So once it receives any of these events, we can commit all those actions in process like of retrieving cause data or calling any other method. But like the problem is like, I cannot have all these four events that I'm talking about in a single umbrella. Like there is no parent class for, like the parent class for this does not even implement the events interface which is kind of a kind of a problem for me. So I cannot really put it under one umbrella. So I'll have to repeatedly make the events, like make the methods called the events like this, like not the abstract push event, like push event or like I'll have to copy this and like just do the same thing for tag and thing. Like this is what I will have to do with this kind of redundant. So do you guys have any better idea for doing this? So I don't immediately, is there a way to, there's not a way for you to declare an event object or your event, a GitLab event object that is the representation that includes those others or does that not make sense? Like the problem is what I wanted to do was I wanted to have a parent object that represents all those four objects which I could opt, like I wanted to have a case by case thing but the problem is like I'll have to implement all those four things instead of having it under a single umbrella. That's what I was trying to do when I tried to implement the abstract push event instead of all those four events but the problem which I got was it did not extend the events interface. So I'll have to implement it redundantly, like it will make the code bigger. Like, oh, I think that's why you were not able to understand the contrast between me. Previously in the GitLab plugin, we were receiving a single webhook. So on receiving a single webhook, it all, like all those things like merge request, merge request hook, push hook, tag push hook, every other hook extended that webhook event but it is not the same case in the GitLab 4G. It is not extending the same event and that is where the problem is coming in the design of the plugin. Did you understand what I was trying to say? I think so. So previously you had a nice parent object that you could reference and now instead of a single parent you've got four objects that are at the moment independent and because of the GitLab 4Js interface they'll probably remain independent, right? Because you're dependent on GitLab 4J. That seems like then you're just, you have to do it that way. I don't see another solution. So no solution, like redundant code. Okay, fine, no, not a problem. That's what I was facing. Other than this in the second milestone, other thing which I was facing is the lack of enums like the enumerations provided by GitLab 4J. I was not able to find the replacement for the state enum like this merge request state only has two options of either reopen or close. While the state enumeration which was already in the GitLab plugin had five options. So I don't know what like... So in that case, are they representing different things? I'm surprised. So like it and the merge request state should be same. I also tried another enumeration called event, state event which was also similar but it was also not having all the things which I wanted. So I was not able to find the replacement. It is actually bugging me because if I am able to find it like I'll be able to debug the code which I'll be so that I'll be able to find the problems which may happen. I'm getting blocked by this. So in this case, what you're really saying is there were previously five items in the enumeration and as far as you can tell, they were all five relevant. It's not that there were only two of them were relevant but in the new case, the new, the GitLab 4J API does not provide all five. Yeah. What this is providing is log then stuff which is not actually required. Like I don't even need this all and log them on. Like I don't know why the... And merge is also not required from this case. I think there is like always data, right? Like what I didn't hear you. Like sorry, I'm in a bad location today. It's open to closed, logged, merged and all for merge request state. The five of them. Open, closed, logged, merged all. Yeah, for the merged request set, you're right. But like where is... Oh, I don't have the state. Damn it. Where is the state? Yeah. This was the state. Yeah. We don't have the reopened. So we can just use open that one. Yeah, this reopened thing we don't have. No, we opened it up there, it did. Maybe. Check around. Like I think we had it in the even like state enum but the problem is it was reopened. It was not reopened. So yeah. Yeah, it's not the same. Is there some documentation on the GitHub? Sorry, the GitLab. Don't they have some API? Sorry. Don't they have some API documentation where they document all of these enums on the GitLab website? Because it seems like that should be the canonical source of truth for what they should be called. Right, finding that. And I found what GitLab for J has done like the merge state event is quite correct. Like the GitLab also shows that but the previous implementation of the GitLab plugin had reopened also. Like I think reopened should be there somewhere if I'm not able to find it. That would be a problem. Well, is there a documentation page on gitlab.com that has all these enums? I found that somewhere like so many tabs. It should be possible to search for it pretty easily, I think. Yeah. And if you add API, there we go. Merge requests API. Yeah, this is where I think... No, that's not the API documentation. I think it was the second link from your search. Yeah. Yeah, it's written there like open, close, merge and all. Like this is what is available in the GitLab for J also. But the problem, yeah, take it. So this seems like the canonical definition of this API. So is the question how to migrate from the old GitLab REST easy version to this? No, we don't have any reopened in here. Right. Like the merge request can be reopened also, right? So we think that this isn't complete? Yeah, I think it's incomplete. But I don't know, like, how can this... It's not incomplete, it's different. Yeah, I would think that Harsh isn't this telling us that some ancient time in the past, there was probably a case where GitLab in their old API and some previous API had reopened, but it doesn't now. Shouldn't we just map reopened to open? Yeah, that's a good question. What version were we just reading on the GitLab API? 16.2. No, but what API version? I mean, because there's the number differently. Right, OK. 16.1, OK, what does the API version... I think it's the API version 5 we're reading or something. And does the URL have the version? I think... Oh, no, it doesn't. Yeah, I mean, I think that's something that I would investigate more is, what about that version history button at the top? Is that a version of the document? No, I meant underneath the heading, underneath the title. Yeah, this one. To the left, Harsh, to the left under the words merge request API under the heading, there's a version history row, three dots, yeah, that one. So click that and let's expand it just to see because maybe this gives us some hint already. You know, I think those are API entry points, not values and enumerations. Yeah, I don't know. I would look into it more to see, maybe you could find an older version of this document to confirm or deny what Mark was just saying that this might have been, that this may have changed over time, which would explain why the rest easy API differs from this document. And if that's the case, then we would know for sure that it's safe to remove it if it's been superseded by this newer implementation. Okay, like this is the only thing which I was facing that because of which I was not able to compile the plugin. And if I'm not able to compile the plugin, I'll not be able to test the plugin, which is bad. So yeah, other than this, I don't think so I was facing any problem. Yep. So Harsh, I like what Basel was suggesting that it'd be good to check if you can find it to see if there is old API documentation that lists reopened. And if they just drop that, all the better. All we need to do is map it, reopen, becomes open. That was actually a good idea. I didn't really think about the history. I was thinking maybe I'm missing something. Well, yeah, and fairly so, right? Because we've got an inconsistency between the source code and the API that we're trying to use. Well done. Other than this, like you can, for referencing the more detail, like I didn't really explain the milestone to plan. So you can also refer to the previous project meet video for that. I just did a quick Google search for GitLab V3 API. And I found a link to the old documentation. Good. So what was the thing that we were interested in again? Merge requests API. Merge requests API. I found the old documentation for it. So you're looking for an enum in this? Yes, the values allowed for the attribute state. The values in this old docs say opened, closed, or merged. Oh, so they didn't even have locked. They didn't even have locked. Yeah. So where is this reopened coming from? Well, but semantically, can't we just declare for all purposes reopened and opened are indistinguishable? Well, I don't think it's a matter of what we declare because isn't this value coming from the server? Yeah. Oh, so it would be completely unused then with the current GitLab API because it will never send us reopened. Well, that's assuming that the documentation is not used in the code base. Like reopened was never actually used. Well, what Mark is saying is assuming the documentation is accurate. And as we all know from writing documentation, it's not always accurate. I would check what the server is actually sending us to see if it, I mean, assuming that this old code that's using this reopened state was added for some use case, I would try to trigger that use case to see if I could get the server to send me that state of reopened. And if we try to do that and this server is just not spitting it out, then we could say for sure that A, the documentation is correct and B, that this use case is just not something that we care about anymore and we could delete that code. Like the reopened thing was used in the action. Like the merge request state and the merge request action are different things. So the merge request action has reopened which I was able to find, but I was not able to find a merge request state as reopened because like the merge request state being open and reopened are kind of similar. So it feels like the biggest takeaway that I would get from this discussion is to try to exercise this use case and see what the server returns because that's gonna ultimately dictate what implementation we use or what our implementation has to be compatible with whatever the server is giving us in the end. So whether the server is giving us opened or reopened, the way that I would do it is just to see what the server is giving us and then write the code based on that regardless of what the documentation says. Okay, so I don't think I have any problem other than this like more on the Gitter channel. Like I'll post the whole sequence of the problems that I was facing for Bessel to actually check what happened and what not happened. Other than this also about the presentation, that I have to give the recorded presentation that I have to give. So I think we'll have to discuss a bit like how are we going to test whether it's working or not? Like John Mark said in the GSOC office hours meeting that all the contributors will have a test drive before the actual thing happens. So how are we going to do that, Mark? Oh, that one's the easy part. We give John Mark an MP4, he embeds it in and he makes sure that he can play the MP4 for your part. Okay, so like we are going to join a Zoom meeting and do that stuff or just I'm just going to send an MP4. It's up to you, whatever, whatever. So I find personally, I'll just tell you personally, I find personally it's easier for me to present to someone else than to talk to my computer screen without someone else listening. If you don't have that problem you are welcome to just record a session but I am happy to be your audience and we would do a Zoom session. We would just record the Zoom with you presenting your screen and talking and describing. And then we give that recording to John Mark. Okay, so that's what our approach like we'll be having a Zoom session but I'll be explaining some tricks and bits of the project that we did and you can take the recording and send to John Mark to actually verify if it's working or not. Exactly, the whole, the goal there is, my thought was it helps for you to have an audience. I'm happy to be that audience. I'm sure others are happy to be the audience. I may even ask you questions during your presentation but then we get a recording out of it and we give John Mark the MP4 and say, here's the recording John Mark, be sure it can be played back during the session. Worst case, if it can't be played back they can always link to the recording separately because we can upload it to YouTube in the Jenkins account. Okay, understood, no problem. So we'll have to complete this first milestone and the second milestone before the midterm presentation like today is 23rd and till the next week like we only have a week left to complete both of them. Well, and the crucial thing for the midterm presentation is to state your results, right? If your results have to be, oh, we didn't quite achieve milestone two. Okay, we didn't quite achieve milestone two. People want to hear your results and hear the, and so absolutely. If you'd like, we could use this session next week to do the recording. We could do a separate recording. You tell us what your schedule is like. So when does your exam period begin? I know you're not available for July 6th. Are you already starting exams next week? Like one exam will be on the 27th but I'll manage, don't worry about that. Like the major chunk of film will come from July 6th. So yeah. Okay, so if we were to do it next week either at this time or some other time that's convenient for you, that would be okay. That's not going to be a heavy burden on your exam schedule. Yeah, it's not going to be that. Like in the next project meet, like because I'll be working extensively on the second milestone. So I may have doubts and I may not have doubts about the reviews that I'll be getting. So I don't think so. We should be using the project meeting for that. Maybe we could use a separate meeting for that. You tell me a time that works for you. Chris and I meet about, or Chris is invited to a session that I meet with the Docs office hours roughly 12 hours before this meeting. So I'm available Friday morning your time. I'm available Thursday morning your time. I'm available Friday night your time. So you choose a time that works for you. Remember, I'm about 12 hours offset from you. So it's probably needs to be near a start of your day or near an end of your day. Yeah, like I can only attend in the night because I always have classes in the morning. No problem, your nights are great for me. In fact, they're really convenient for me. So that's good. You let me know when. Like on which day are you free? Like any day, if you say you'd like, well, let's see, you attend the GSOC office hours, right? Yeah. If you would like, we could do it immediately after that. Yeah, no problem, sir. If that works for you, we could just say, hey, you attend GSOC office hours. Let me double check my work calendar, but I think I can break loose right after GSOC office hours. Then I should check mine. Yes, yes. Immediately after Google code office hours on the 29th, if you're available. Yeah, I'm free. Okay, let's do it then. Okay, so it's going to be an action-packed week now because a lot of things have to be done and I'm late successfully. Harsh, I think you're doing fine. And I don't think you should overstress yourself about just that presentation is crucial, right? Because that's a requirement. We've got to do the midterm presentation. And if every other thing is not done, okay, that's less of a worry, particularly don't let this harm your exams, right? You need to, your university education is intensely valuable, keep focus on it. Yep, so thanks for the patience, that's for it. I had a question about the project plan with regard to getting the test suite to pass. And I was wondering when we're going to tackle that with regard to the other things, including, you know, web hooks and things like proxies and such. So from my initial impression is that getting the tests to compile is already, they're already compiling with the milestone one code that you've posted, but they aren't passing yet. And my sense is that it would be good to work on getting them to pass before the proxy server stuff. But, and the reason why I think that's more important than the proxy server stuff is that the proxy stuff is not covered by test automation. So we don't need it to be working in order to get the test suite to be working, in order to get the test suite passing. And I think getting the test suite passing is more important from a project point of view because it gives us more confidence in every change that we make. So I think it would be desirable to get that passing sooner rather than later. And the only thing I'm not sure about is whether the test suite depends on this work that you're doing now for web hooks. And my sense is it probably does. So I would guess that it might make sense to work on the web, get the current PR merged for the infrastructure, the basic migration to the basic migration to GitLab for J, and then get the next pull request merged after that, which is the web hook stuff that you're working on. And then after that to get the test suite passing, not just compiling, and then after that to do the proxies. That's my rough sense of what the order of operations should look like. But am I off base here? What's your opinion about the order that we should do these things? Like I don't have any problem. Like it sounds fine to me because it will help us to determine like if it's working properly or not. Like we are only able to do interactive testing. So it will be helping. Yeah, and in terms of order of operations, the only, we can have multiple pull requests open at the same time. The only one that needs to be merged as a dependency of the others is the current, is the very first one that you have open right now. So because both the web hook change and getting the test suite to pass would depend on that being merged into the project branch. And so, yeah, so it's pretty, from an order of, from a dependency point of view, I think it's important to get that first one merged into the, currently the project branch is empty other than disabling the tests. But getting this initial pull request merged into the project branch would be good because then we could start building on top of it with these other things. And we could even do this concurrently and not be blocked on anything. So... The other thing is like the implementing the proxy is not adding much code. It is never about testing. So it will also be helpful. Yeah, yeah, but that pull request, again, depends on the first, everything depends on that first one to introduce the library. And I think we're pretty close on that one because I reviewed it yesterday and it looks pretty good. And there's only a handful of action items. But I think you should be prepared to test it again. And there might be just to set the expectations. I think there might be one more past a feedback in retesting after the one that you're working on now before I would approve it. Because just from my past experience, I usually, when I'm reviewing something of this size, I'll usually have like a design review and then an implementation review and then a cleanup review, just making it nice and tidy. So I'm on the second of those three right now where I think the design is correct and the implementation is pretty good, but it could be better. And then I think once you implement the last set of suggestions, I think I'll have one more pass and that'll be just kind of tidying up the loose end. So it's nice and pretty. And you might have to test it a third time after that. But I'm hoping that would be no more than three iterations. Like after the first one gets accepted, it would get a bit easier because the first one is the extreme one, like the hardest one to get merged. That's right, that's right. About one more thing that you were asking in the review, like you were telling about removing the processing exception, which was from the REST easy thing. So how the GitLab 4j API exception works is it encapsulates all those exceptions of, like the processing exception, the webhook, sorry, the web action exception, all those exception in the GitLab 4j API exception only. So when I'm writing that I'm able to get an GitLab API exception, I'm actually getting exception that you expect REST easy to give. Like I can get a processing exception which is encapsulated in the GitLab API exception and it will show you the processing exception itself when you debug it. Like, did you understand? Like you don't actually get the exception. The only thing that's wrong with that approach is that, or the only thing that's undesirable about continuing to refer to some of these Jersey types is that it's really an internal implementation, detail of GitLab 4j, how it chooses to communicate with the server. So it might be the case today that GitLab 4j API exception or whatever it's called, GitLab API exception, it might be the case that today that it's wrapping a Jersey type, but you could imagine that in the future they might re-implement GitLab 4j to use some other HTTP client. For example, I know that the Docker API has recently switched from using NetE to using HTTP 5 from the Apache project. And there's other examples of this where Java 11 now comes with its own HTTP client built in which a lot of things are switching to as a way of getting zero dependencies. So basically the point is that from an interface point of view the only thing that we should rely on is the types that are officially exposed by GitLab 4j. And I think that's just GitLab API exception. So that's why I left the feedback that we should remove references to any other exception types even if they are still being emitted by the current implementation. What I was trying to say was I will remove those extra RSTC based exceptions but you asked how are you testing it? Like how are you testing with it? It is the same thing or not? That's what I was trying to tell you that GitLab API exception is also like it is the same as that exception like processing exception but it is just encapsulated in the GitLab API exception. So we are actually getting the same thing. It is not different. Yeah, yeah, so, yeah. Right, I understand. I mean, the, I think my question was I saw you were changing some of the old code that was unwrapping this unwrapping basically a nested exception. And I knew that if you were changing it it meant that you had tested it. Because otherwise there was no reason to change that line. But I was curious as to how, because I wanted to do the same thing myself and explore it a little further. And I didn't understand, I hadn't quite figured out how you had tested it. So I figured I deduced that you must have tested it and that I wanted to do the same test but I just didn't know how you had done it. So that's why I was asking. Just simply use the debugger. Like that's what I do. Like when you use the debugger, you get the same question. My question would have been how to get the server to give you an exception. Oh, that's what you're talking about. Yeah. Okay, okay, okay, okay, I'll find that. Because I wanted to do the same thing and see how it worked. And I couldn't figure out how to get the server to give me an error or at least that particular error. Okay, it's fine. Like there are a lot of errors that I've tried out and also I'll see what I, what I can do to help you on that. Okay, so then there's any questions? Well, so there's currently a number of PRs that are open. Do we wanna close the draft PR because that's been subsumed by the milestone one pull request? Is there anything in that draft that's not also in, yeah, so I think we could close that one. And then the second pull request is still, the one that's doing the web hooks, that one's still valid, but I think it'll shrink a lot once the first one's merged and it's rebased. Because it's based on the first one. Is that impression correct? Yeah. Okay, great. I think we're all on the same page here. So I'm really excited about getting the first one because that, like you said, that's kind of the bulk of the hard work. It gets a lot easier after that. Yeah, okay. Yeah, this project is very front loaded as are all library upgrades for the most part. So this is some good preparation for what you'll be experiencing after you graduate from the university environment. I don't know, inexperience. You'll see this kind of thing in your career. It's, yep. Any other topics then that we need to discuss on the crucial question around current work and a second milestone? Are we okay there? Harsh, anything else from you? Anything else from Buzzel? Well, which milestone in terms of milestone numbering in terms of milestone numbering, do you want to, but for, what are we considering milestone two to contain? Is that going to contain the webhook change and the getting the automated tests running or is it just the webhooks? No, it's webhooks and the cause data. Like I'll be separating out the cause data according to the different events. So it's the webhooks and the cause data. Mostly the second milestone is about creating a more modular plugin. Like it was a bulk of a thing. Like each and every part of the code was very bulky. So I'm trying to break it into different small chunks for making it more maintainable. That's what the second milestone should be about at least. And the third will, like the third pull request will be about those tests and the fourth will be about those proxy settings. Got it. Okay, so getting the test to pass is going to be a milestone in and of itself. Yeah, I broke it off because it was a Docker based testing, right? So I have to work up quite a bit on that. Well, no, I mean, the testing that I had in mind was just getting the current test suite that's running on trunk, running on the main branch, which is not the Docker based suite to work against your new, to get to work against your new, basically to work against GitLab for J instead of REST easy. So that's not the Docker based test suite. But that's the existing test suite. And in your milestone one pull request, those tests weren't passing. So the question is when do we want to work on getting those tests to pass? And I think what you're saying is you want to do that in milestone three. So should I do it in the second itself? Three is fine. Right, I don't, Basil, I don't think you were arguing that it should be any sooner than milestone three. You were just observing milestone three sounds fine. It doesn't have to be in milestone two harsh, not at all. Okay, so I'll make a separate pull request for getting the tests working. Like the test pull request. Yes. Yeah, and my point is regardless of this project plan, it could be done concurrently with the, it could be done concurrently with the milestone two work if desired. There's nothing blocking it other than our own desire. There's a presentation, right? I think you have to forget there's no technical reason they couldn't be done concurrently. The only reason to do otherwise would be for scheduling purposes. Yeah. Okay, cool. Okay, so we've covered the milestones then. We've talked about the presentation. Harsh, you and I will at least meet for the presentation recording right after Google Summer of Code office hours next week. And be there too. Oh, okay, great, Chris. If you join us as well, that would be wonderful. That really would be great. Yeah, sure. Okay, and then other topics that we had on the agenda. Let's see, we had, I think we could skip the mentor checklist. It feels comfortable that we're there. Oh, upcoming timeline. So remind me, Harsh, it was that you have an exam, 27 June, 2023 and then exams, multiple exams, July 6th. Yeah. Great. Okay, and you're sure that we won't be disrupting you by having you do that presentation on that after right after Google Summer of Code office hours. Nope. Okay, great. That covered all the topics that were on my list. Anyone else have topics that we need to be sure we discussed today? No, all clean from me. Okay, great. Thank you.