 for the Jenkins project. It's the 1st of June, 2021, at 7.30 a.m. India Standard Time. Delighted to be here and remind everyone that we are, we abide by the Jenkins Code of Conduct as we interact with each other. So what I've got for an agenda today looks like generating the change log was the top item and then reviewing the plug-in installation manager tool documentation from Sudhakar. So those were the two topics that were on my list. Dheeraj, is there anything that you would like to add to the agenda? No, nothing. I think this is fine for today. Great. Okay, then let's get started and the goal here was actually to have you generate the change log. Do you want to share your screen, Dheeraj, and take us through the change log generation process so that I can watch over your shoulder and... Sure. I would really love that. Okay, I'll share my screen right now. Can you see my screen? I can. Yes. Awesome. So I went ahead and run this command, which is to capture all the PRs that have been submitted on Jenkins with the help of this core change log generator. And it found all the PRs and... Okay, pause. Pause. There's already some output there that... I assume you're okay if I interrupt you. Yes, definitely. Please do. Okay, so for some reason it's saying checking range from Jenkins-2.293 and that is too wide of a range. So that it should say... So checking range from Jenkins-2.295. So in your repository, in the Jenkins repository, could you do a git pull? I'm just not sure why it didn't get the tag for 2.0. Interesting. So could you get pull minus, minus tags? Okay, so do a git log space minus, minus annotate. Yeah, I think that... Oh, no. Sorry, I have to look up my command just a minute. I have a shortcut for it that... Okay, the command is git log minus, minus graph minus, minus decorate. Yeah, okay, there we go. All right, so here is head. Yeah, so... Oh, okay, let's do even simpler. Quit from that and add one more argument. Space minus, minus pretty, P-R-E-T-T-Y equals one line, O-N-E-L-I-N-E. Perfect. Okay, so it shows... Now I got to do the same thing on mine to see if I see the same thing that you see. Okay, you're on the master branch, that's correct. Okay, so four, five, seven. Maven release. For some reason you don't have the... Okay, so could you do a git remote minus V? Let's see what your remote is. Ah, okay, there it is. All right, good. Now I understand. So we need, we need you to also add the upstream repository so that you get the tags. Okay, good. So git remote add upstream space HTTPS colon slash slash github.com slash jankinci slash jankins.git and enter. Now if you do a git space pull, space minus, minus all. And what that says is please pull from all of the remotes that I have listed and it will now pull in the additional tags. There we go. Okay, good, very good. Right, now you want to run that command because now it will tell us... Yes, there we go, the core changelog generator, correct. And this would have worked just fine as well if you had initially cloned the upstream repository instead of your fork, but because your first clone was of your fork, it only brought in the tags that existed at the time that you created the fork. So tags don't get magically copied from the upstream to the fork on each update of the upstream. Right, so we need to add it as a remote first and then pull it. Right, right. Yeah, exactly. Understood, awesome. Nice. Okay, so and those look like, let me do the same command. Yes, okay, good. So we're ready to take next steps. Awesome. So I'll open my VS code, right? Yes, exactly. Great. So this one is the weekly and this one is from the changelog that we have generated. So I'll have to add it again. Okay, this is it. So it says the date of 29. Okay, now why would it say the 29th? Today is, that's interesting because today is June 1, right? For you in your time zone, your today is, but you can correct it or that's fine, that's just a proposal. So let me look at my changelog.yaml just to see. Yeah, mine also says, oh okay, mine also says the 29th and I think that's because that's probably the last time there was a change merged. So that's not unreasonable. It's just saying then the newest commit is from the 29th. Okay, good. Oh, that's fine. Okay. So I'll change it to 6th June. Well, and actually it's okay, you can just leave it as is that file at the top is intentionally read only because we don't want you to change the file at the top. You'll paste things into the bottom that have the changes that we want. Yes, I totally forgot about that. I'm sorry. Oh, no, that's great. This is because at least for me, I like that the top is read only because then I know that I won't do any harm to it. Now, and you'll make my life easier and everyone else's life easier if you'll put the new empty lines above that do not edit this file block. So whoops, whoops too far. Line exactly put it right there. Right. The idea is that that do not edit this file is always the bottom of this file. It's we want that to always be reminded of people even if you have permission to write to this repository directly, do not modify this file. You'll break site generation. Oh, okay. I'll keep that in mind. Yeah, you're safe because you don't have right permission to the Jenkins.io repository directly. Oh, okay. And let me just refer to what was done here was in date and changes and start with everything. Okay. So let's wasn't it changes? Is that correct? The popping this part? That's right. Okay. And now you lost a dash there on that very first line. And this is YAML. So every every character matters. And right there you go. Is the indentation correct? indentation matters very much and you've got it exactly correct. Okay, awesome. Coming back here. Okay. Now, could you scroll? Could you scroll up in that bottom window? I need to see which which was the preceding version? 2.294. Okay. So then that means that we've got some additional changes we need to make in your Jenkins.io file, IO repository as well. So we'll need a before we go any further here, we need to get back onto a command line where we can do some get updates in your Jenkins.io repository. So just go to Jenkins.io. Yes. Okay. All right. Now if you do a get remote minus V. Same thing. Right. So add the upstream. And this case, it's github.com. You'll want two slashes there. Yeah. Slash Jenkins dash infra slash Jenkins.io. Get very good. Enter. And now get pull minus, minus all. Perfect. Okay. And so now we've got upstream slash master. So now what we want to do is now we need to create a new changelog branch that will be based on upstream slash master. So what branch are we on right now? Could you do a get branch command? Okay. So if you say here, you should be able to say get space merge space upstream slash master. And it may tell us, Hey, I can't do that. You've got some changes pending in a file, but let's try it. Okay. Okay. So it says, Oh, I can't do this because you've got changes pending. Let's just do a stash show get space stash. And what stash does it says remember my local changes and save them temporarily hide them. Okay, now do it new. Now do you get get merge? Okay. Yeah. Oh, it's interesting. A conflict. Okay. That's okay. So here, the you, you, this is great. Visual Studio did a wonderful job of showing you where the conflict is. Let's go ahead and resolve that conflict. And the way you resolve it here is we want to keep the version that is on the bottom half of that and delete the top half. So, so delete lines one, one, zero, nine, eight, nine, nine and one, one, one, zero, zero. Okay. And then this one exactly. Now we need and you want to get rid of the empty lines that were inserted there as well. Do you mean here? No, no, you don't want to change the indentation. The line above it needs to be deleted. There we go. And the line below it. This one. Right. Exactly. Now are there any other conflicts that it's showing? Yes. Okay. So this may indicate that what we want to do then is let's stop what we're doing here and let's go resolve the conflicts a different way. So back to your command line to resolve the conflicts. Okay. Because really we don't, we don't want your copy of the branch to get out of date with what's on the master. I assume there's nothing on your changelog dash 2.294. Oh, whoops, whoops, this is the wrong branch name, isn't it? Right. So we need a new branch. We don't, okay, so get space merge, space minus, minus abort. I should have been paying more attention. Abort, right? Correct. What we're going to do is tell it, hey, we don't, we don't want to do this merge at all. Okay. Now we're going to check out a new branch for changelog 2.296. So check out minus b changelog dash 2.296, space upstream slash master. So what that command says is create me a new branch, name it changelog dash 2.296 based on upstream master. And now if you look in your weekly YAML that just changed in Visual Studio, Visual Studio code, you'll see that it's got a 2.295 below the place where we're at right now. Yes. Okay. So now you're up to date. And now the next thing we're going to do is we're going to insert the 2.296 changelog in there. Awesome. So let's do it. First of all, let's say paste and change the version, change the date to 2.29, I think. Well, we wanted 0601 because what we're doing is now is this date in this place is what day is the Jenkins release generated. And it will be generated today, the 1st of June. Okay. And that bracketed, yeah, you want to delete that because now we're going to insert the actual changes from up above in changelog.yaml. Great. Awesome. So let's do that. I'm not sure the orientation is right. Yeah, usually I just go up to the top half of the editor and copy the whole block. Oh, you mean this one? Exactly. Right. Line five there all the way to the end. Just copy the whole thing. These comments as well, right? Everything. We want everything because then we're going to edit it. So let's come back to here. Right. Okay. Very good. Yes. But yes, it's amazing. Okay. And so now this is where the editing part comes in where you have to actually delete lines in order to make it look the way you expect it to look. Sure. So the title here is fixed request submit usage. Usually what you want to do is you want to ignore all of the text about the to-do and the PR title and the author has provided the proposed changelog. So at line 11163, that's, yes, the one you've highlighted. That's the one that we need. Okay. Even you, if you want the regression to do this one? If it's a yes, yes, we do. And that's when we'll have to do some research to find out what, which version I first introduced that regression. So yes, we do want that. And now the guidance in the style guide says, says we should, we should start with a present tense verb usually. So usually we'd say fix regressions in, right? And, and because our readers won't probably understand the word number 5405, I would delete that and say just fix regressions informed submissions. The, the human beings who are going to read this won't understand the numbers. Right. So do we, do we want to delete this as well? That part, I don't know yet. Let's, let's look further. So now we need to decode when that regression missing submit button value informed data. So because this is focused on end users, I don't know that we care about telling them about HTML unit. So maybe we should delete the missing submit button value informed data because that's users, users don't care about automated tests that run with HTML unit. So just everything. No, I would, I would keep the double submit request because I think that one, so, so just the phrase missing submit button value informed data, I think that should be deleted because it's talking about HTML unit and HTML unit is a Java testing tool, not a, yeah, there we go. Okay, double submit in HTML unit is again still the Java testing tool. So you can delete that as well. And then now the unwanted form validation, that one is a real user, user problem. Okay, so now how do we say this as a sentence? So fix regressions, inform submissions, maybe replace the colon with the word from. What do you think? And so yeah, take out exactly, I think so. And now we need to go actually into GitHub and find out where this, what version this was first introduced in. Need to get the PR number, right. We'll either need to go to GitHub or we may also need to go to the Jenkins JIRA. But one of the two we hope will tell us which version, no, no, actually you are in the right place. We want not Jenkins.io. We need to go to Jenkins core. But we want to go to the version you forked from. So we want to go to the upstream. So right below your username slash Jenkins, there is the, exactly, we want to go there. And now look at the pull requests there. And now the one we want is PR number, whatever the number was. Try it. Yeah, I've never tried searching by PR number. I like that. Yes, three closed. So we want exactly, yeah, very good. Okay, so trying to understand. So now what we have to do is we have to read this and see if it will tell us when the regression was first introduced. Oh, oh, oh, look, I think it may already be in the top. Very first line says see the Jenkins bug report and the earlier pull request. So open that pull request in a new tab and let's go look at it. Oh, that's great. Same tab is also fine. Okay. Yes. Okay, this will now tell us which version first included this. Okay, so now click the commits tab at the top. So that one. And sometimes we get lucky if you click the individual commit, it will tell us the first version it was released in. Oh, it does. Oh, very good. I like that. So do you see the, do you see the series of dots at the top? No, up about three or four lines right below master. There's a Jenkins dash two dot 295 and three dots. If you expand the three dots by clicking on it, this tells you which tags got the, hey included this commit. Oh, okay. And so this says this change was included in Jenkins versions tagged 289, 290, 291, 292, et cetera. So that tells us the first version that introduced the regression was 2.289. Okay. Okay. So back to your Visual Studio code. And the regression is in 2.289 instead of to do. Okay. Oh, this is the reason we searched for the version of Jenkins. Right. And then one of the, one of the rules of style here is we always end these sentences with a hard stop with a period. So insert the dot. Yeah. Great. So we've, we've got one of them done. And let's keep, let's continue on this on the same line. I have preferred to put it on the same line. I don't know that there's any mandatory for me. It's always been easier to have it on the same line. Yeah. And there's a two brackets side by side. Is that good? And, and I think we should remove the first set. So it would say without, yeah, exactly it's fixed regressions informed submissions from unwanted form validation in any browser. Yeah. That for me. Yes. This looks good. Certainly there were also automated test regressions that told us there was this problem. But, but for users, the problem is about unwanted form validation. Okay. Okay. All right. So we are ready to look at the next one. Sure. So Oh, I have it here. So this is the second one. Exactly. Right. So here to here. Okay. So we're going to delete this one because we don't need it. Yes. We will look here in the plugin manager show which plugin keep a plugin that was split from code installed. Okay. What does that mean? All right. Okay. Now, okay. Now we've got it. So, so now we've got to think more carefully. What does the, okay, this is saying show which plugins keep a plug. I think it's talking about dependencies or between the plugins. See, for me, the, the, I like the PR title better than the proposed change log. Right. So could you open PR 54.72 and let's look at it together because I find the thing more understandable in the title than I do in the right. Okay. Maybe there's some comments. So sometimes there are comments from, from, from other people saying, Hey, this is not. So scroll through this a little bit. I think it may be comments from Daniel Beck that clarified that it's not really showing implied plugin dependencies. Okay. This always annoyed me. Keep going. Okay. This one. Okay. Okay. There it is. This. Okay. This is Daniel. All right. So for explicit dependencies is not as bad as for detached plugins at every other plugin you have installed. Okay. Scroll down. All right. So now Tobic says, Okay, I see the problem. I'll try to limit. Okay. So show implied plugin dependencies quick and dirty change. All right. Okay. Keep going. Okay. So fix the wording in the message. All right. So maybe, okay, maybe we need to look at the actual commit. So dear Oz, you're, you're getting the experience here of the same thing I do. Sometimes I have to read the source code to decide what's the best way to say it. So, so show the commits and let's see what the message is that it's going to give to the user. So show the second one. It says fix the wording in the message. Yeah, that one. Okay. There are still ah, ah, okay. Got it. So, so I think what we should say is report the number of plugins with an implied dependency. Right. Because, because it does not show which plugins keep a plugin that was installed from, from core what it's showing is there are account of plugins with an implied dependency installed. Okay. Now, now, speed the message. Well, well, let's go back to the, let's go back to the source code because I may have missed something on the, so look at the preceding commit in this one. This one. Yeah, that one. Okay. So it says if it's not detached, return an empty set. Okay. Okay. Scroll downwards. Okay. Go back up a little. Oh, there it is. Whoops. No, you had it. Go scroll down. Okay. Here it is. Look at line 177. Okay. It says when the implied dependent size is less than 15, then it lists each of them. But now if we scroll a little further, you'll see otherwise detached many dependents. Okay. So, so what this is doing is it's being smart. It says if there are less than 15 dependents, show every one of them. If there are more, just say that there are a lot, that there are very many. Okay. Now we have to go back Visual Studio Code and decide how we say this. Okay. All right. So, show, and that now makes more sense to me. This, the notion of an implied plugin dependency says the reason it's an implied dependency is because the plugin was originally inside Jenkins Core and has now been split into a plugin and therefore the dependency is implied, not direct. So, so this, there's the, okay. So now, how do we, what if we said show, yeah, what, okay, Dheeraj, what if it were show implied plugin dependencies or account or account of dependencies of account of dependencies for show implied dependencies or account of, for plugins split from core. But is that really accurate show implied? Show it's plug, okay. Now thinking about it's show which plugins, keep a plugin split. Okay. Back to the pull request because I think I may have just said it exactly the wrong way. Okay. So, and now go back to the comment because back to the conversation around this. So, yes. Okay. And Toby says this plugin, it's functional. Okay. Previously it said you can't, you don't disable this because others may be, may rely on it. Now it says this plugin is dependent upon by these other plugins. Right. Because in this case, the tri-lead API plugin, its functionality was originally inside Jenkins Core but it's been separated out and therefore these other plugins have a dependency on it that is implicit, not explicit. Okay. Back to Visual Studio Code. Yeah. I think, I think what you've put for PR title is a, is a reasonable description. Show implied plugin for plugins split from core. And now end it with a hard stop and we're ready to do the next one. Awesome. So this one is the next one. It's checkbox missing fill color. Yeah. And this one, I like the proposed changelog very much. We should, rather than better cron-tache, we may just say improve contrast. Improve contrast for the checkbox in the long term. Yes, that's right. So let's delete everything else. Is this right? I think so. Yes. Okay. Now this one says it's too long. I'm sorry. Yes. And Daniel, when Daniel Beck writes a changelog, I can almost always just take his text exactly as it is. So I would just, Daniel is very, very good at his writing and very, very capable of writing a good changelog. So he maintained the changelog for years before I did it and he did a much better job. So Daniel's very, very good at his writing. So I would just take his writing exactly. That's great. I hope every changelog is written by Daniel. Right. Exactly. That's okay. Now it, you may need to, you may need to scroll through this one because it looks like he put a hard stop at the, yeah, so put the hard stop there and take it out from, right, exactly. Okay. I think this one's good, right? Right. Okay, let's move to the next one then. This one is remove jtid from core. It's about removing a dependency. It must be updated to explicitly declare a dependency on jtid. That's a lot. So what do you think? Yes. So I would, this one I think is well phrased, but we need to use a specific, let's use a specific format earlier in the file to insert a reference to a link. So take, I think we should take everything that's online 11193. We can, we can, yeah, so that, the developer colon, that is intentionally there. This is, this is a change that is relevant to developers and not to typical end users. So what we do is we keep, we delete line 89, 90, 91, and 92. And now, now there's, okay, it's, it's making a reference and I've preferred to do one sentence per line. So on line 89, after the first hard stop, put in a new line, right. And now there's a, this has a hyperlink in it to the NIS notification lamp, right? That's a hyperlink. There's a way to embed hyperlinks. It's using a thing called a reference. What you'll need to do is search backwards for a reference. Yeah, so look for the word reference references, I think it is, in this file and we'll find an example. There, there's a good example. Yes. So copy those three lines. And let's go back to that place and we'll put them in. I just pulled all the curtains, I'm not able to see my screen clearly. Yeah, so for me, control end usually jumps to the bottom. Control end. Nice. Thank you. So we were at this one, JDA. Yes. So right at, right above the word messages or message, we want to insert that thing you just copied, right? Okay. Okay, so now the first, on line 89, we say pull instead of issue. So on, yeah, there it should be pull. And then the pull request is 5521. And you'll see that on line 85. Right, exactly. Okay. And then the issue is there isn't an issue, but now we're going to do a, now we need the URL syntax. And so for that we need to find an example in this file of somebody that's using. So should I search for issue? Yes, well actually search for what we're, what you're searching for now is probably URL colon. Yes, that's it. We need those two lines. Exactly. And now replace the URL with the link to that NIS notification lamp. And then the words, the title should be NIS notification lamp. And we should probably call it notification lamp space plug-in because people may not, may think, oh, it's a physical lamp. It's not. This is a plug-in that runs a lamp. Right. So do you want to remove it from there? No. That's what I would do is I would delete that phrase. This one as well, I think. I'm not sure if it makes sense. So if I remove the comma. Right. Does that make sense? It does to me. Could you scroll to the right so we can read the rest of the sentence? Okay. Yes, that looks reasonable to me. Awesome. So I think this one is also ready. I think so. Yes. Awesome. So we have, I think, last one left here. And this one I think is just a mistake that we need to make into a comment. So it's saying bump the spring security bomb. I think we've got 5,505 that we need to earn insert. Exactly. A duplicate of that line. So it is 5,505 and this one. Exactly. And then we will just delete this, right? Correct. There has to be two lines separating them, right? I think just one. At least I've only used one. Okay. Let's keep it that way. All right. Now if we're lucky, we should be ready to do a make run. And if you're, I think your visual studio code actually can even allow you to do the make run inside of it. I don't know how to do it. I'm not a visual studio code user. So using a terminal like you're doing is great. You can explore visual studio code later. Let's try it out. Oh, I think. Okay. Let's go with. Oh, no, that was perfect. Look, the terminal prompt appeared. Don't be shy. The terminal prompt appeared. It's a great way to learn to explore something. So do a PWD there. Let's see what directory it's in. Okay. So go to your Jenkins.io directory. And now type make space run. And let's see if you can do it all inside your IDE. Nice. Now this will take a little bit because it's going to download a Docker image for the Ruby runtime and all sorts of things like that. And do we need this file or should I just close it? You can close it. You can close it. We're done. We've, we extracted the information we needed from it. So while I'm working on this and I have, let's say, some doubts in the PR title that I want to do. So how can I get help? Like we had some problem in the first one, I think, right? This one. So the main thing I suggested by you is to go through the bits and try to understand, right? That's, that's what I've had to do, right? And if, if, if you don't know what to say, say, make your use what the author provided and, and then hope that the code reviewers will correct it because certainly you and you and I are not expected to read people's minds and know what they, what they should have said. So best guess is open it up and let's see how it looks. Yes, please continue. Were you saying something? No, let's look at the, let's look at the site. Well, it's busily sharing its screen with us and we're generating a huge website. So it should be slow. Okay. So now if you click the download button and it will navigate to change log, right? Okay. Now what we see here is it's showing us 2.295 and we need it to show us 2.296. So there's a file we need to go change in the, in, you can use it and use Visual Studio Code to change it. Now I have to figure out where it is. I think it's in content, content underscore TMP. Yes. Okay. So in the content underscore TMP director, you see the latest core.txt, open that file with your editor. Okay. Done. And it says what exactly change it to 296. Save it. Done. And then switch to your terminal where we were running the make. Let's see where there should be. Yeah, we don't want a new terminal. I'm not sure. Where is, where is the list of windows in Studio Code? Oh, oh, oh, that's good. Okay. That's the, this is for searching. Maybe it's under the go, go, go, the go, the go menu. Go to file. No. Is it under the run? No. So maybe in the file menu? Oh, oh, wait a sec. Oh yes. There it is. Okay. It's on your screen. Right hand side, a little bit away from your, away from your mouse. So to the far right, there's a three colon bash. If you drop that down, there'll be a two colon make. Yes. Interrupt this with a control C. Okay. Is this going to stop? Yes. Now do run the make again. And, and I'm confident there are even better ways to do this in VS code than what you and I are doing. I'm not a VS code power user. I believe there's a concept of how you can in Visual Studio Code use it to actually perform a make like this, but, but this will, this will at least be good enough. Nice. Okay. So I'll be, I'll be the one that will be doing this weekly on basis, right? That's the idea. We would love to have a rotation of multiple people doing this, but it would be great if you're willing to do it at a minimum. This is a great win that will have you and I will work together so that you can submit what you've done for this week so that yours will be your, you will have written the, the changelog for Jenkins 2.296 that will release in about 10 hours. Very nice. So actually I would love to do all the weekly releases. If anyone else is interested, then they can contact me or else I'll be doing all of them. That's, and that is great. I'm very, very grateful for your willingness to do that. Thank you. Your, the time that you're at in India is perfect because you could do a Tuesday morning your time and most of the people in Europe haven't, haven't started work yet and most of the changes that will occur in the, in the weekly release are already in. So you've got a big benefit for us. If you're willing to do this, it's a great win. Definitely. Okay. So now what you need to do, excellent. What you need to do is take a screenshot of this. What's new in 2.296 piece? Yes. Just this area, right? Correct. That's right. Just the area that's about 2.296 because what we do is we like for, yes, and, and that's the area. Perfect. And save that because we're going to need it later. 2.296. Okay. So now we need to, now we need to create the poll request. So we want to add and then commit everything. Right. So we need to do a get at, well, so first let's do a get diff. But yeah. Okay. So this shows 2.296. Yeah, that looks good. Oh, whoops. Okay, there's one. I would love to get rid of that trailing. You see the red block there? The red box at the top right hand corner of the screen. I'd like to get rid of that because it's that's a trailing blank on the end of the line. It was the thing for Jay Tidy. Further down. There it is. So line 93. Right. So save that. And you notice when you did that in the window below in the terminal below, it says change detected for file such and such and it rebuilt the site. So the nice thing about doing this inside studios, you can change it in studio, it will detect it and give you a better view of the site. Wow. That's really great. And do we need to run it again? Get diff? Yes, it'd be good to run it again just to be sure that it does what we did what we expected. Yep. So Q to quit. Could you do, okay, there's a prompt showing up on the screen here, which hints to me that you may be ending your commands with a different command than you want. Type the command jobs J OBS. Yes. So what's happening is it appears you're pressing probably control Z to stop things. And what that's doing is it's actually putting the job in the background rather than stopping it. Oh, so if you type the command FG, FG will bring it into the foreground again. Now press the Q key, the Q, Q, the letter Q to quit. Oh, now do jobs J jobs and you'll see only three jobs now. Now do FG again. Q Q jobs. Now we'll show you only two jobs. Right. Now do FG again. And now do a Q. And now jobs should show only one. And so FG again. Right. So, so what you were doing is you were using a facility of the of the bash shell and many Linux shells have the same thing where you have the option to put something in the background in case you want to come back to it later. But most of us, just like you, use our window manager to do things and keep everything in the foreground. Makes sense. Yes. All right. So, so now we're ready to you've done the get diff. So it's time to do the get add and the get commit. It's going to change nog. That's correct. Good. It says one file changed. That's the right thing. And yes, some number of insertions and deletions. Great. Okay. Now, if, if you're willing to do if you have you ever used the GH command, so try it, type in GH and just hit enter. Okay. No GH command. So, so now there, there, you could, we could go ahead and do the, and I don't know what that snap command would do. I would use a different command to install GH than the one they're recommending. But, but let me suggest to you what it is, and then you can decide if we should spend the time to do it. You and I can go through and submit this pull request using just get commands and the GitHub web pages. So that's very easy to do. I've found that I really like the GH command because it lets me submit pull requests from my command line without having to go to the GitHub UI. Oh, that's really nice. So, so maybe, maybe for this time let's just do this pull request the old way and another time we'll go through how you do use GH because we're sort of running out of time. So do your get push that you were going to do. Sure. So we want to say get space push space origin because we don't want to try to push to upstream. Now hit enter. Oh, you're a very patient soul. You used username password. Okay, that's, that's very good. You get extra points for being patient. That's great. I tend to use private keys because I don't want to mess with that. Good. Okay, so, so now it gives you the hyperlink there create a pull request. So all you need to do is open that hyperlink. And this is where we'll need that screenshot that you created. So there it is change locked. So copy in the screenshot. So, yes. Oh, look at that. That's fine. That's that do you want me to do it again? I don't think you need to do it again. You are welcome to do it again. But I think it's just fine. If someone complains about a box on the right hand side, they're complaining about the wrong things. Okay. So fix regressions informed submission. Sorry, go ahead. What was your question? No, I was just asking what should we do right? Do we need to write anything messages? I typically don't write anything. I just submit it as is. All right. So I just need to create. I think so just create the pull request. Okay. This is it, right? That is it. Now, now you and I will be able to do this one more time. So next Monday, I'll still be available. And so we've got another chance to do this same exact set of steps. If you're okay with this, we will do it again next next Monday. Yes. And that way, that way you're comfortable with it. The following Monday, I probably won't be available because I'll still be recovering from my surgery. Okay. But next week, we'll do this together again. Definitely. I'm in. All right. Well, dear Aj, thank you very much. This has been excellent. Thank you so much for your time. All right. I'm sorry you have to deal with a beginner like me. Oh, I am delighted with your, you're doing wonderful things for us. Thanks very much for what you're doing. Thank you. Thank you. My pleasure. Thank you so much. Have a great day. Bye. Bye. Bye. Thank you so much. Bye.