 Welcome. This is Shikot Africa inclusive naming project. It's May 17, 2022. Thanks for joining us. So what I thought we should do today is propose to review the sheet of the results to date and talk about next steps for the contributors. Some of the items, let's say, remaining actions for several items, and it's worth discussing those to see where we're at. Anything else that should be on the agenda today? Nafisa, anything that you need to put on the agenda? I don't think I have anything. Okay. I think that's fine by me. Great. Excellent. Well, thank you for being here. So we'll, we can be brief as necessary. So here's, here's the current sheet I reviewed yesterday, each of the call request that had not been merged, or rather I look specifically at things that listed as changes. The changes means is there was a review was performed. As a result of the review there was some action that the contributor in this case Catherine would need to take in order to have it be acceptable for someone else to to merge the pull request. So as an example on this one, the change uses uses an incorrect term in this context the word master in this context doesn't mean controller it actually means the definitive or the authoritative list. Mark, sorry to interrupt the time afraid you're not sharing the right window. Oh, which window am I sharing. Oh, that's a Google Drive. I didn't help at all. Sorry, let's try this again. Thank you, Bruno. Thanks very much for catching that mistake. All right, so here's the, here's the share of the screen, the correct screen. And it should show up as now do you see an inclusive naming planning sheet. Yes, indeed. Thank you. Sorry for my mistake. Thanks very much. Catherine and and peace. Thanks very much for joining what we were proposing to do is review the sheet and the results to date and look at remaining action items that are still open on the items on the sheet and then the next step for you is write your final report and post it to community dot Jenkins.io. The other item was questions and answers if you have any questions that you'd like to ask. Questions and answers that are questions you'd like to put on the list. Peace or Catherine. I'm doing the last meeting we proposed the topic. I don't know if you I remember you wrote it down. Okay, let's take a look at this. Yes, I can certainly do that if you if you would like a recorded session if you would like that I am happy to do that. And that I'm more than pleased to do I've got the slides available and we can do it thanks for the reminder. Okay. So that that I can do that absolutely. So let's let's put that in as a marks. This is a tutorial from she code Africa. Meetup. That was not recorded. I can certainly do that. Very good any other. Okay, great then let's. I'd propose and let's quickly get through these items. And then we'll we'll spend most of the time and peace and Catherine you can remain on the line. The others are welcome to be there if they'd like. If you already attended the session last at when it was presented on that Saturday, you're certainly not required to attend, it's, it's just an introduction to using get effectively for open source contributors. So here's what I had on the inclusive naming planning sheet. Thanks very much for recording your poll requests here because it made it very easy for me to go through and do the reviews. So if an item is listed as reviewed it means it's been reviewed and the review has been approved to say yes, this is ready to merge. We still have to depend on a maintainer to merge it, but it's been through the review process by either me or Angelique jarred or both. And so now there are two that still need changes are there there are several it's not just to there are several that need changes. And maybe the easiest way to see those is let's do a filtering here so that we don't have to do anything other than filter. Now, if we just switch this to state something with changes. Okay, so there are several here that had that the poll request event submitted that a change is needed in the poll request. And what we did what I did is I proposed the change Catherine what you'll need to do is go in, accept that suggestion, and then let it commit it, and then I can go ahead and approve it. I will do that. Great. Thank you. Okay, excellent. And this is a relatively small set so congratulations to the two of you for for that accomplishment that's really wonderful. If we look at the number that have been merged and reviewed good good submissions there and then the ones that let's see what are the ones that still have a closed duplicate and with changes there's our set. Thank you very much. Thank you. Just a question. I did make a couple of changes. I don't know if you got to see them. I think I did because when I, when I visited these last night, when I looked at these last night late. These are the only ones, most of the others that you had, you had submitted I reviewed and change their state here. Let's clear the filter and links. There we go. And so when when I went through them, I went through anything that had not been reviewed and and marked it as either left the word changes to say oh still more changes are needed like this one. There are others where, hey, the change had been applied. Then. Yeah, so here it is 12 hours ago. This change needs to be reverted so that one really does need changes before the contributors can can evaluate it, or before the maintainers can evaluate it. So did that address your question Catherine. Yes, it did. Great. Thank you. Thanks very much. And hopefully you also have email notification from GitHub telling you that hey that feedback was given. Yes. Yes, I do get the notifications. Great. All right. Okay, so any other any other topics on the review of the sheet. Okay, then next topic next steps for the contributors. Right your final post and put your final report and posted to community that Jenkins.io. Let's look at an example here. So, peace I think yours is the one I'm going to use as the example so just a minute let's find it. This one. So, so this is for me a really very nice, nicely done summary starts with headings. It helps me know what sections I should read over who you are, what the project was more details about the project, and then a summary of hey here's what we did. And here's how it worked complications and we very much want to know this. So, getting the work environment setup was very challenging for peace, and we spent two weeks working on this we really and therefore the feedback she provides saying hey, we need to be sure this is much easier for people when they join next year. Those kinds of things and experience gained is again a good, good story so for me. I think this is an ideal way of giving your final report. So take it take those topics and fill in your blanks now, you might also consider inserting links to some of the work that you did for instance you might put links in there to the poll requests. That's a good way to remind people hey, look we did not only did we do an awful lot of work here is the specific work we did. Any questions there a piece any insights you want to offer on your experience writing it. I don't think so. Okay, I was thinking. There was something I thought of when I was writing like, am I supposed to include other mentors like forgotten the name and jelly. And you are certainly welcome to refer to them express thanks for their help, especially if you were involved with them directly. That's no problem, but you don't you don't need to feel obligated to mention any mentor so the fact that you mentioned me is is very kind but not really necessary. So what you did is great. If you want felt to mention Angelique or other mentors that would be fine as well but it's not required. Okay. Super. Thank you. All right, so we've got. Now the deadline here the deadline is, I believe. May 29, I think, is that right. Deadline is next week or two. And so better. What was that again. May 28 we got the email from she code Africa. Thank you. Excellent. Okay, so be sure you're done by the deadline. We want to be sure you're properly compensated for the work that you've done. And thanks very much for being part of this journey. If you're okay with it then the next topic would be this get tutorial. Does that does that work okay for the two for the two of you Catherine, and, and peace. Yes, it does. Great. All right, so what. Something else I'd love us to cover if it's possible that that pipeline from the way we've been working on the plugins to now. I think pushing them to get that sorry to Jenkins. And just seeing that that workflow. And seeing how, how exactly Jenkins comes into play with the plugins that we've been working on if at all you can still see the work that I'm doing on GitHub. So just to see those differences, and also to see in the future how to how to work Jenkins generally, because I still feel like the Jenkins platform is a bit confusing. Okay, good. Yes. So, so you'd like to see how Jenkins is involved in the pull request evaluation. Is that a, is that a fair way to say it. Yes, it's a, it's a fair way to say it and also, there's another section I think you removed, which it did not involve the current work that we are doing, but in case someone was to adopt a plugin. And how to make changes on the plugin and also to, to do the pull requests, pushing your work to Jenkins and how it relates basically in that whole process. Okay, and, and that one, yeah, that one, we can that one is a much more involved thing but you can you can certainly look at that one through this five part video series here that will guide you through that. Okay, thank you. Very good. Okay, so, and if we wanted to we could certainly spend time on the becoming an open source maintainer. The idea was, we meet today we'll talk about, we'll do the get tutorial. We could do this one on May 24. If you're still interested in it. Yes, I am. Good. Okay, then let's plan to meet next week as well. Super. Thank you. All right, so then, then how about let's take on and so that you know where the slides are that do this inside our chicote Africa contribute on 2022 shared folder is where I put this link to these slides that I'm going to use. So let's start with, with these. This is a set of hints that I assembled as part of chicote Africa contribute on on tips and tricks for get. So let's talk about get in terms of what it did, what it does and how it helps us contribute to open source. This is fundamentally a source control system. Its job is to track changes to source code files as they go through time. And it was originally created by Linus Torvalds to help him with the Linux kernel. It's now widely used 93% of the 70,000 respondents to a stack overflow survey said that they use get is a very, very good skill for any software developer, anyone who's going to deal with source code is likely to encounter get in their work with it. So why, well, get is an interesting source control system because it provides you a local copy of the entire history of the repository. By being a local copy of the complete history, it gives you very, very fast access. There's no network traffic to compute the history of the repository. Local comparison commands have all the benefits of operating on local copies, instead of doing network based copies to see what's changed. Search facilities likewise help us very rapidly find things inside to get repository because it's all local. The benefit of that local, local nature of it is that it makes it easy to create branches. I can create branches and discard them very, very quickly and throw things away very quickly. I'm also allowed to remember points in time by tagging things. So that lets me tag releases or tag things that are especially valuable in terms of fixes. Each of these features come from the fact that we have a full copy of the history locally. Now, what I wanted to do here is let's look at a demonstration. And we're going to do a get clone. So I'm going to start with something that I want to operate on. And I want to do some work with let's do some work with one of the plugins that you were you were working on let's take how about the pipeline model definition plugin. So in order to clone this repository, I go to GitHub on the green button here for code, I click the copy the to the clipboard there it is and now I'm going to say get clone that repository. If I change into that directory, the entire history is from most recent may have 2022 to the original commit back in 2016 are all included in this repository and I could check out any point in that history with no network traffic with no overhead, and I can see branches. I can see remote branches. It gives me all sorts of visibility into what's what's available in this because I've got local history. So we've seen the clone we've seen the log now let's see one more step. What if I want to look at something that somebody else was doing maybe I want to look back in the history how did release 1.4.x look. I'll do a get check out minus be that and minus t origin slash that. So this is going to give me a view of the repository at release 1.4.x. And when I do a get log you'll see back in 2019. I did this release, and we could read. Oh, here's what changed this is where the beta designation was removed and there was this fix that was implemented. All because I can do a get check out. Now gives me now my branch list says hey I have a master branch but my current branch is release 1.4.x. So maybe I want to switch back to master I can switch back and forth between branches very easily with get check out. It just works. Now get at its foundation is a content tracker. It tracks the content of files. And that being a content tracker is a relatively important thing and part of the importance of that is because of this picture. It's as though command line get has this tiny little database inside of it that lets us prepare a transaction to a staging area, and then commit the transaction. So having this concept of a staging area, and it really to me it feels almost like a database in that I prepare a set of changes, and I can assemble those by multiple commands at this at this at a piece of this. They are prepared into this thing that get calls the staging area that little yellow box. And then after I've prepared this subset of things added them to this staging area, then I say get commit to push them all the way into the repository. Now all of those options operations are still completely local to my computer. There's been no network traffic whatsoever here. I added something to the staging area by doing a get add, and I add one file two files I had a part of a file. And then I, after I've get completed the set of all the things I want to add into the staging area then I commit them with get commit. So let's let's take a look at how this might work. So, I need to do a checkout I need to check out a branch and let's do a fix something. So I'm now on a branch. And what should I fix piece if I remember right there was a use of the word master somewhere in here wasn't there or maybe Catherine that was you. Find one that is a branch names aren't quite as helpful. Okay, I'm gonna have to cheat and go back to the to the poll request that was proposing the change because then I can find the exact change that is being made it was shame on me let's go here and follow the link. Okay, the change is. Okay, white lists. Ah, there we go. That is definitely one change that's needed. So exists in this. So let's find that file. Okay, here's the file that needs to be fixed where this says Jenkins master it should say Jenkins controller. So now if we do a get status. We're going to see the first part of this. Where is it in the in the in the flow of things right now my get status has it only in my working directory so I'm in that left hand green area. Now from there, I'm going to say get add, and there are shortcut ways to do this, I could say get add of the directory name and it will add everything that's changed under that directory. Or I could give the whole file name and it would add just that one file, or sometimes when I'm really lazy, I just say get add dot because that says add everything that's changed underneath this director and I'm going to do that. So I just did the get add, which means I've taken the step of moving this proposed change from the working directory into the staging area. So now when we say get status, it's going to say, Oh, notice it changed color, instead of the red modified it's hinting to me green, ah, and the what do you need to do with it hint says if you want to undo this you use this get restore minus minus staged get is very good about telling you what steps you should take for the next step when you offer a command. So if I wanted to undo this, I would get restore minus minus stage that file. Now that I've, I've put it into the staging area this yellow box, it's time for the next step, which is, let's commit it. I actually like to use the minus V argument because it shows me what's changed in preparing the commit. So what this says is here please enter the commit message. It's going to commit this file and here in purple and sort of cyan. This is the old text, and this is the new text so it's giving me a hint now it it also alerts me. Although it will be ignored. So I don't have to worry about what's there it's not going to appear in the message so I say replace a master with controller in a comment inclusive naming improvement. Thanks Catherine for doing it so I didn't have to go find it. Now when I do get log, we'll see here is here is my text, and there's my branch fix something. So, I've now gone all the way into the repository. I'm over in this next step. So let's go on from there. Let's also see what's changed by looking at get status. I've shown that to you now we can compare changes with get diff things like get diff master shows me what changed in my comparing my commit to the master branch. Get log, where we see Oh, there is this here is the set of log entries that happen between the master and the place where I'm working so I could also say get log master dot dot fix something. So get log and get diff are effective ways to help me see what's happening. There's another command that you may find helpful this get stash, where sometimes we do something that we're in the middle of doing something maybe I'm changing the read me. It has too many blank lines at the end. And I realize, oh, but I'm on the wrong branch and I haven't finished my work there. The get stash command will allow me to save changes that haven't been staged. It will allow me to save all changes that haven't been committed. And then I can bring them back later so in this case I started modifying the read me but I don't want to include this on this branch so I'm going to stash it. If I do a get status it shows me there's no change. I might then do a get check out remove blank lines. And I do a get oops get check out minus be removed blank lines minus and then upstream slash master. Okay fine origin slash master. If I do a get stash pop. This will bring back the change that I had made to read me. And you'll see it now here is the deletion of three blank lines. So now I could commit here. And that work is committed. Now I've got three branches, the master branch, the remove blank lines my current branch, fix something and my master branch independent. So stash can be a helper when you get interrupted and need to do something else. Now we can also retrieve remote changes from others with get fetch and merge those changes with get merge. One example of that might be that Catherine and I may be working on something together and I need to pull in her changes. I could let's let's do exactly that Catherine you're okay if I bring in your changes. So if we look at her repository. I need to add her repository as a remote. So get check out minus be work with Catherine. I'm going to start a new branch that that is going to be representing my work with Catherine and I'm going to add her repository and I'm going to fetch her changes and anybody else's changes that I have. So now what we see is, Oh, there we see it Catherine has a Catherine slash inclusive naming branch. Remembering what branch I'm on, I'm on work with Catherine, and I can say get merge Catherine slash inclusive naming. And here we see Catherine's work replace deprecated terms in various files being pulled in. And the reason it's nicely merged here is I started from the master branch. And fetch and merge help me if I want to do work with others. And now if I wanted to I could push this to to my branch to a branch in my upstream repository with that. Oops get push set or upstream have to say the correct branch name don't I. I don't get remote. I don't have. I don't have a way to push it because I haven't yet created my own copy. So I'm, I'm temporarily stuck will have to get there in just a minute on how I push it to make it visible to others. Any questions so far Catherine or peace. I have a question that that process of pulling repository and fetching the latest work. I often see a common challenge that developers face. And I think is when someone is trying to push their, they're trying to commit their work, but they're using the wrong branch. Is it possible to demonstrate that with what we are doing. I think so now let's be sure that I understand what you're asking though so sometimes you see a message that says, I can't push what you're asking to push. Is that what you're saying or ask your question again maybe I need to listen more carefully. So you often see a challenge, especially when you're working on a group project where I think it's either trying to commit or trying to pull the trying to fetch the latest work. And you find that there's, there's a common challenge of trying to commit to the wrong branch. Yeah, so I don't know if it's also similar to what you've just demonstrated. But I think what you've done is you've selected a specific branch instead of this committing to the master right. Correct. Okay. Yes, so so it's a relatively I think you're under, you're describing a relatively common problem that, hey, I forgot. Let's let's clear the screen and so get status so right now. I've got a branch that I'm on called work with Catherine, if I instead check out master. And if I make the mistake of making an intentional mistake. Right, so I'm going to commit this intentionally wrong or commit to the master branch is usually wrong. I think that's what you're saying right is sometimes people make a commit to the wrong branch locally and then they say oh I want to push it. Yeah, and then it ends up messing up the master branch. Right, right exactly so. So I'm going to borrow another command so that I can do this demonstration example really quickly I'm going to use a GitHub command line to quickly connect. I'm going to connect local working directory to my fork. That's the command GH repo fork so just a minute. Okay what should be the base repository that's correct and add a remote. Okay, so I'm now going to make the mistake of even going one mistake further. And I'm going to push my mistake up to my central repository up to the to my fork. So if we do this, we see commit to master is usually wrong. I have to go back to just a minute. Get push. So get branch where are we so let's go to this one, which was it was this the one which one master is the one we were making the mistake on. So we're on the right branch. And I'm going to make the mistake worse by pushing it to my origin repository. Okay, so I'm going to get get push origin. Now if we look at what what I just did. The one master is ahead of, or after upstream master. And that says, now I've, I've got a problem. I've created this problem myself but I've got a problem. What am I going to do about my mistake. I didn't want this to be on the master branch so the first thing I do is I create a new branch. And I push that to origin, so that I don't lose my work. Okay, so step one, don't lose your work, push a new branch branches are cheap, they're fast, they're easy. So now if we look at things, we see I've got a new branch, and it's matched with origin and new branch and then there's this thing called master that I mistakenly did an origin master. So now I'm going to do a get checkout master. Now this is telling me your branches ahead of upstream master by one commit and that's a bad thing. I need to fix that so I'm going to do a get reset minus minus hard upstream slash master. I'm going to make my local master branch, the same as upstream master again with this reset command. Now when we look, we'll see master matches upstream master, but I still haven't fixed the damage that I did by pushing to the remote master. So for that I need to say get push origin, and it's going to tell me, Oh, dear, you cannot do this because updates were rejected because the tip of your master is behind its remote can counterpart. And this is correct. It says something exists on the remote that doesn't exist locally. And that's because I made the mistake of pushing it to the remote. So now this is where we pair program so Bruno you're going to watch me, and we're going to do a pair programming exercise. I'm going to make a very dangerous command now. I'm going to get push minus minus force origin. Okay, I make Bruno pair with me on this one is anytime I use the minus minus force argument. I have to think about. Do I mean it because this is going to do something that is more severe. It's going to actually delete the most recent commit on the master branch of the remote on origin. So Bruno, are you okay if I do this. Oh, No, no, I'm going to do it anyway Bruno. Okay, so I'm okay with that. Thank you so so the reason for that little bit of ceremony on be sure that you're paired minus minus force is a really dangerous option. You should think very carefully before you ever use minus minus force. We had mistakes happen in the Jenkins project where someone inadvertently force pushed to a number of repositories in a loop and caused us all sorts of surprises and problems. So please don't use minus minus force without thinking about it and talking with someone else. So Catherine I'm now going to push minus minus force. Now when we look at. Let's look at the branches here so now we've got you remember we had a new branch so let's check out new a new branch. And if we look at its picture, it's one commit ahead of upstream master and origin master and master so my local branch, my fork copy of master and the upstream copy of master. Did that address your question Catherine. I did. You've actually covered one of those challenges that you often face. You know when you go through all your options and you find yourself thinking should I just force everything. And we figure out that but yeah thanks for that. Well and and one of the other benefits here is that because get clones are relatively lightweight. You have the option of just throwing away your entire directory throwing away the whole thing and cloning a new copy saying this is such a mess I don't want to attempt to clean it up. I'll just delete the directory and clone a new copy and try again. Those are also perfectly fine. There's no shame in saying, it's easy to clone another copy. Very good. All right, so I think next stop on our on our conversation then is, let's take a look. There's there are some other tools that are sort of advanced capabilities. You want to learn about get rebase. Some of those where on your first second and maybe up through 10th or 20th time using it you probably want to talk with somebody, because it's a little complicated. If you've got to find a problem get bisect is this amazing tool that will do a binary search of the commits in your repository and check them out at various points while you look for a problem. The gc will garbage collect the repository so it'll throw things away that have might be cluttering it. And if you're using a nice shiny relatively new version of command line get the get maintenance command is a great helper. Now all those things you can learn about there are lots of places that will teach and tutor you on how to do rebase bisect GC and maintenance. The other story was command line get is great, but working together on open source project most oftentimes means working together on GitHub. And so what GitHub gives us is a centralized repository, where many projects choose to store their official copy of their source code. And I've noticed it that it is nicely secured industrial grade backups, they have special repositories that they use to keep things archived very carefully. So very nicely maintained, and a common use for open source projects. The crucial thing there that you've seen is pull requests or how you propose change. You submit a pull request. You don't have right permission to the official repository but you're proposing a change to it anyway, and we get to retain code review conversations we chat back and forth we make proposals, and ultimately we get things merged. It also has the concept of releases releases allow us to document what's happening in a particular in a particular really version of the of the product so for instance if we look at Jenkins core on its repository the releases just today. It was two dot 348 released four hours ago. And this tells us about, hey, Java eight is reaching end of life for Jenkins, and there have been some things removed and some new features, all nicely documented by the, the GitHub releases facility. Now, we could talk through pull requests but I think you're, you're pretty comfortable with pull requests and releases and issues are just good documentation facilities. So I'd like to go on to the next topic, which is how we do GitHub command line interface, because this one is when I don't want you to miss. I, I really like and I showed you one example already. You remember I did gh repo fork. That allowed me to do the same thing from a command line, as I would do from the GitHub user interface where I pick the fork button up here when I pick the fork button. It offers to create a new fork for me well I did that from the command line and it was very easy to do and made my life much simpler. So I call the gh command. It's available for Windows for multiple Linux variants and for free BSD, and I think multiple architectures including AMD 64. So Intel arm 64 32 bit arm system 390 if you like mainframes and power PC works great. So what I use the steps that I need to use to get started with it is I start first with the gh off command, you authorize, and what you do when you authorize is use you. Basically you're logging in. I will tell us some of the options I've already done the authorization here. I did a gh off login. And what it then does is it offers either would you like to authenticate through your web browser. Would you like to paste a token for me, one of those two and then I'm in. Let's try this one, gh off status to see what my status is so I am logged in as marquee wait. It's using HTTPS and it's using a token and they very wisely hide the tokens value. So I can manage repositories with gh repo. So gh repo offers. If I'd like to clone a repository or create a new one. The ones I'm most frequently use is I very frequently use gh repo sync. I get copies from the upstream upstream repository and I use gh repo fork. The others are certainly available and you can use them try them explore them. Then if you want to work with pull requests you use gh PR. And in my case gh PR, I use it an awful lot, because it says things like list me all the PRs. And I'm a maintainer on a repository. I can or even even just as a someone involved so here we should see Catherine I don't see. Oh there it is good. Let's say I wanted to work on Catherine's I wanted to help with Catherine's I could say gh PR checkout 521. But what it's going to do is it gives me a local copy of Catherine's changes, as they're committed on that branch now maybe I say, I want to help out by merging master into Catherine's branch. And now when we look at the differences between her branch and master this is what we see. Hey, that that was good. We have a local copy of a pull request that I can use for experiments. GH issue will let you work with issues and GH browse will let you open things in your web browser. We are near out of time. What questions do you have or are there other things you'd like to see. So I do have just a confirmation. In the earlier brief that we got there was a section about tasks of building and testing plugin. So this is the part where Java was supposed to come in right. Correct. Okay, just wanted that confirmation. Yeah, so if I wanted to build if I wanted to actually build this plugin. I would check what version of Java am I running. Yeah, I've got a Java 11 that's good. I'd check what version of Maven I'm running. I've got Maven 3.8.4 that's good. And then I would just do Maven clean. Now if I want to skip tests for speed I skip tests, and I do verify. And now it will, it will compile this plugin. And you'll see, yes it's downloading a big chunk of files because I don't have all those dependencies locally. But yeah that command Maven clean verify is your friend. And so what it's doing now is it's going through a whole bunch of steps of compiling the code, compiling the source code compiling the tests, preparing to package the source code package the built binary, ready to run automated Cs I told it to skip tests so it will skip them. Now it's running a static analysis tool called spot bugs that's used to look for common coding errors. And those kind of things just keep going. This one actually oh, oh, this is fun Catherine, because this one highlights a problem in the change. So I ran this compile and it says, Oh, your compilation failed. And why did the compilation fail, because this file. Let's see what's the easy way to get that full file name my tech my console is too big. So when I look at this file, I'm going to bring it up in my editor. Let's compare it with master branch. And here is a change that was made in your pull request that's causing it to fail to compile so I'm going to save that. So when we do get status we'll see oh marks made a change. And if we do a get diff, we'll see that the change change the word s here to white lists. So now if I do that Maven thing again. I should fix that problem. So that's how you compile the plugin that's that's part of the exercise now, thankfully for this project we didn't generally have to have you compile the plugins because most of your changes would not be involving source code that would be affected by the change. Now what did we get this one says, Oh, maybe it says that I don't know what to go. No, something else. So that file also has a problem. Ah, yes. Okay, this one's another one. And again, this one's in the pull request. So if I undo that those two changes and now when I let's try that compile again, and it's making progress. So this particular plugin is actually a what's called a multi module Maven project. So it actually has multiple components inside the inside the plugins repository, and those multiple components are listed here. And what it just did is build each of them. Any questions so far. Okay, this is a good. Thank you for this because it's on record. So in case someone wants to adopt a plugin to refer to this. Thank you for that. You bet and next, next time we meet will plan to go through the, the contributing is to contributing to open source, I'll put a link to the contributing to open source document into our folder here as well. So that if you want to look at it in the future you'll be able to find it. Maybe I should just do that now while we think about it. So Google Drive contributing to open source. Okay, so here's this document and all I'm going to do is create a shortcut, add shortcut to drive. And we want to go to Jenkins, she code Africa to one contribute on 2022. So now what you'll find in that contribute on folder is here's a link to the contributing to open source document. And it's 27 pages of my various ways that you could help adopt a plugin. Thank you very much. Well, and thank you thanks for thanks for joining the session on I see comments in the chat. Oh good thanks Kevin, good. So Kevin's posted a link to how do you install get the GitHub command line for windows into the chat message very good. If there's nothing else I'd propose we end for today please don't forget to submit your final report so Catherine for you piece it looks to me like yours is already done and ready. And we'll talk to you again in a week. All right, thank you very much Mark. Mine is in progress. Very good Catherine. Excellent. That's, that's just want to be sure you get it done in plenty of time so that we don't have any question from anybody that yes we did it and we did well. Okay, I've done, I've done an article around open source last week. So, I'll mostly pick most of the points because I've covered a lot about Jenkins and she could pick a lot of points from that. And I think that's that's very much in the open source way good for you. Thank you. Thank you. All right, thanks everybody have a great day I'll post the recording I hope within 24 hours. Bye. Bye.