 There we are. So good morning, good afternoon, good night, everybody. Nice to meet you all for this GSOC office hour for the 7th of July, where we're going to discuss a few matters around the GSOC, the Jenkins GSOC program. So I have a few points that I'd like to share with you in the beginning and then afterwards we're going to do a round table to see the various projects. So first announcement is that the GSOC project criterias have been published earlier this week. So Hayd Raj. So they have been published, they have been discussed first with org admins, then with the mentors. Now they're open for the public and for you. Open for comments. If you have improvements, comments, questions, doubts or suggestions, you're welcome to use it during the, on the document and say if do you want to walk them through? Did everybody read them or we can eventually walk through them? I think we can walk through them. Maybe? Yeah. Okay. Well, I'm going to do that. So I'm going to share that screen. Okay. There. So does everybody see my screen with the project success criterias? Yes, we do. Yes. Okay. Good. Okay. Because I didn't see you nodding because you don't have your camera. Okay. Just a joke. So here, these are the criterias that will help us as a global team. So mentors and contributors to evaluate did we have a successful Google summer of code when we reached September? So the first question we're going to ask is do we have a functional and or usable product artifact feature delivered at the end of GSOC? The meaning of that can be fine tuned or can be adapted. So we can clarify that even further. But there can be good reasons why the initial idea didn't work. But currently, I don't see that in any project. So I leave it very open. What is delivered? But we need to have something at the end being a report, a description, a jar, a plugin, a documentation or whatever. So there must be an outcome. Second point is this outcome needs to be documented. And so it's not only to have it done and see here it works. No, it needs to be complete, correctly described. For the process, development process. And so we want to see that the intent, the project plans, the various functional and technical decisions were correctly described and made public and discussed publicly. So we don't want to see somebody hacking and working in this in a cave on this side and Sully pops comes out and there has been no discussion. I don't see that at all for the four projects here. Did the GSoc contributor learn and demonstrate the ability to work in public, which is a very important point for working with open source. It's a complete different way of working than in a company or professional environment. So that means sharing progress, give ample opportunity for review, interact with the community, etc. Did the GSoc contributor learn and demonstrate adequate communication skills? So written, verbal, so we'll have some presentations, work interactions. So this is another important skill that we want to to have the contributors getting proficient. And this is the purpose of the learning process. Now per project, you can define other criteria. I just want to emphasize that this is not a university exam. This is not a death march. I made my military service, so I know what that means. So that cost what it costs, even if you need to crawl, you absolutely must reach it. This is not the purpose. The purpose is to have an enjoyable experience, to learn things and especially learn to work together. So this is the purpose. I think we started this adventure on this base. It's only I wanted to have it written. So as a guideline, and it's also an advice from Google to have them written down. Are there questions, doubts, clarifications needed on this? It's clear to me. We'll take a couple of seconds more. Don't hesitate to put comments in the document or what you do, the method you feel to give your comments improvements or okay. The next point is we're going to reach an important milestone for you. I know it's intimidating, but it's part of the learning process. So we're going to hold the Jenkins online meetup on the 21st of July at this time here. Thank you for Alyssa to have organized the meetup. So it's announced now. It has been announced also on the various social media. Don't forget to register to it because you will receive the link only once you have registered. We can walk through that afterwards, but I'll send a link to the meetup page or I can get the link and put it in the chat window right now. Just give me a minute, John Mark. Yeah. Okay. Thank you very much for that, Alyssa. So just a reminder. It's a 15 minute presentation where and you can use slides. Slides are a good way to do that where you explain the crowd. I don't know how many people will be there. So don't get scared about that. What the purpose of your project is? What is the plan for your project? What is it about? Explain it in simple words. Where are you standing now in this idea, in this project? Where are you? What are the difficulties you're facing? What are the challenges you're facing? What did you already achieve? So you tell the story. This is where we are. Bragging is allowed and encouraged because you all did tremendous work and you achieved good results up to now. Maybe not what you wanted. So maybe you're putting the bar there. But you have a lot to brag about and be proud of. If you have the possibility, but don't fret out if you don't have it ready. But having a demo, something to show helps people to understand what you did, what's the aim of the project. Just remember you have 15 minutes to do it. Ask your mentors for advice or to rehearse or that. A good way to rehearse that. I don't know if you have done that already. A good way to do it is to use either Zoom or whatever conferencing system that you used to and you record yourself doing that. And you go a couple of times through the presentation and that way you will first know, are you able to explain everything that you want to tell the people in the allocated 15 minutes? I can tell you it's hard to keep it in the 15 minutes. So rehearse it and you will feel much, much better. Especially if English is not your native language. Are there questions about that? So don't hesitate. If you want personal advice about that, reach out to your mentors. You can reach out to me. I've done that so many times that I can maybe share a few tips on that. And don't be afraid. We're here to have fun and learn together. Okay. Next point. I've seen a lot of very enthusiastic dedicated people working on GSOC. Very proud and honored to have been selected in GSOC and putting a huge amount of energy. Meaning that I see messages very early in your time zone and very late. So I fear somewhere and I'm speaking here as a grandfather, grandfather. So I fear that you're really putting everything in it. There I need to say you an important thing that I want you also to learn is that to keep a good work and life balance in all that. So it's a one-time experience. It's a great experience. But nobody will win if you burn out. On it. So just to clarify the expectations, the contract, moral contract, is that during the coding period, the project is estimated at 175 hours for 12 weeks. That makes about 15 hours per week that you can arrange. Now, this is the goal. I can really understand that you want to explore things, that you're taking more time, you get into troubles. It doesn't work that you're spending more time. I'm doing exactly the same. So this is why I allow myself to give you this advice is be careful. It's fun. It's great. But keep the balance. So learn to hook off. I remind myself each time, now we're different generation there, but don't go on Gitter or Slack. Is it necessary to go during the weekend on it? At a certain moment, you need to shut off. If you feel the necessity, and I had this discussion with one of you, here I want to think or I have personal things that I'd like to sort out. It's perfectly okay to say here, I need to take a good breath. I want to go. I don't want to go to my parents or this or that to have a break. So I insist on that. And the last thing that very often, especially learning. Now, during the generation that was born with that, but Slack, Gitter, males are asynchronous communication means that means it does not require an immediate reply. Read it at certain times when you allocate it. It does not require an immediate reply. I don't expect also an immediate reply. So I sound maybe a little bit too advising. I feel it's my role to give you that advice because I've seen a huge amount of super dedication. I see very enthusiastic young people. I wanted to give that advice. Are there questions, comments, or people that don't agree with what I said? I'm open to discussion. Alyssa, just I didn't sound too fatherly or too. I think it's good word of advice, and I suggest our young contributors take that in because it's important. We want you to be successful, we want you to be happy, and we want you to have a life as well. So it needs to be said. Thank you, Jean-Marc. So here. Now, this was a long, long introduction. I'm sorry, but I wanted to share that with you. Let's go around the various projects. So let's go. Dheeraj, how's the plug-in health going? Yes, hi everyone. So to tell you about how the project is going. So in the previous week, we worked on mostly some of the enhancement tasks, and there were some bug and core related or chore related DRs as well. So to quickly tell you what we worked on, first of all, we had some problems in generating the reports on our CI configuration. So Adrian helped us in that. So he opened a PR and corrected everything, and now it works very well, and there's reports generating as well. After that, there was one enhancement PR that I submitted to simplify what was going on in the project, and there are two tasks in progress right now, and they're like, it's like we're in that zone where we are going to climb the hill, like the main task that's going to come up in near week. So that is in progress right now. That is adding a JSON object inside of our database. So that is the interesting one. So its PR is currently in draft, and I will be soon publishing it for review. And there's another PR that is under review right now. So these two things are there, and by next week, hopefully they would get merged if nothing's wrong with if it looks good. And after that, I will be working on the main task of designing the rules system so that we would be able to generate some probe data, and they would be, we would be able to show some demos by July 21, if possible. Yes. Hey, great. So I think you're really in the middle of it now. Yes. Okay. Good. Thank you. Jenkins file runner action for GitHub. Yiming, can you tell us a little bit where we're standing? Okay. So last week, I did three things manually. So firstly, I supplemented a pull request about the method of how to package the Maven banners and additional plugins. So now it is based on the cache action. You can see it in the pull request. But some actual implementations needed to be polished or changed after the weekly discussion because they are not good enough to be a feature. So it is only my personal idea. And secondly, I submitted a pull request about how to create Jenkins file runner image that bundles newer Jenkins core. So, and, and I think I don't need to, I think this pull request does not be needed at all because the Jenkins file runner project all that way helps me to release a new version with newer Jenkins core in Jenkins file runner upstream project and thirdly, I also tried to add more details in the project page and the demo project page. Yeah. That's my work last week. Okay. Good. And just a point, don't hesitate to propose enhancements upstream or to help Oleg in things because Oleg has a very tight schedule. So don't hesitate, but I don't know enough there. So, and discuss that with your mentors. Okay. Something else, Yiming? Oh, I don't have anything. I have any other problems. Okay. Good. I'd like to hear that. Automatic get cache maintenance. Who is she cash? Willis. Hello. So, this week, I worked, I and Mark, I, Mark, Rishabh, we all worked on setting up the SSH, you know, so that I could connect with Mark's machine and run the get, you know, and check whether which gate get a version supports which get maintenance tasks that we have done a detailed analysis on that and come up with the results. Also, I tried fixing few logical errors which were there in the code. So, there were like one, two errors. I tried fixing those. That's it. That was what I've done this week. I'll, this, so I'll be adding, so this week I'll be adding how, you know, how to add legacy get maintenance into you know, the get plugin. So, yeah, that's it. So, the last point was adding legacy. Get maintenance. Okay. Is there something you'd like to add? Oh, nothing. Impediments, problems, worries. Nothing as of now going good. Going strong. Is it, you feel, you feel good for 21st? Big question. I know you're a little bit shy. So, don't hesitate to ask me help. Yeah, sure. Or one of your colleagues. Whoever you feel good, but don't be, don't worry. Thank you. Okay. Yeah. Next one. Vian. Hey, everyone. We've been working together. Yeah. So, first of all, I would like to thank, thank you a lot. So, for getting the release done. So, that was one of the biggest checklists for the week. So, I checked it and the artifact resource release wasn't good. And also try to include it as a dependency and everything is working great. And on my side, this week was like a PR week for me. So, yesterday itself, if I counted correctly, I guess five PRs were merged. So, and the few things that were done was adding search on pipeline steps reference. So, this was a follow up to the plugin list that was not merged. So, maybe some sort of a modification with that and getting the source ready. So, it's merged and it's working on the website now. So, that was the first thing that was done. After that, the data type parameter list. So, that has also, that public person pipeline step docs has also been merged. So, now we can see the updated versions on the website itself. So, everything has gone into build. After that, the updation of the metadata was complete as we did together. And so, for those who don't know, we have updated the repository to support the plugin manager that is required by the step doc generator repository. And the reason that we separated the artifact from the main repository was in the future, some other projects can also use that as an artifact. Those who don't wish to start a new Jenkins instance, but want to use the power of the plugin manager that comes along. So, that has been done and set. So, now I guess only the CD part for that is left. And I think John Mark will take care of that also. And please ask me for help if you want in any of those things. And now the goal for maybe this, so tomorrow we'll have a meet with Christian and the goal would be to complete the tests for the repository. And the main test would be to see if the plugin manager is getting consumed by the reactor, which is present in the back end step extractor, and we'll just write some test queries to see the results are matching them or not. So, those would be the tests overview as of now. So, once that is done, we can set up the next cycle I guess. So, yeah. Okay. Good. I worked together with Vian. I had the pleasure because I don't get the opportunity as much anymore, but to do some technical stuff and help for the release. Something that we observed and that might be a general interest. The teacher again. A reminder for everybody is you bump in a problem. And here in this case, we had a problem in the generation of the Java doc. There were some illegal parameters. This error was not caught by the CI because the goal was not explicitly done, but generating the Java doc is something that's run at the release when you build the release. And this is where we discovered. This is exactly when you have a problem that happens in production. You fix the problem and Vian fixed it very, very quickly. Thank you again. Although it's you've been working here. We're online late. But the immediate thing that you need to take in account is what tests can I add? Or in this case, what is the goal that I need to add in the CI process, in the Jenkins so that if we do that again, putting the wrong character in the Java doc, it gets caught during the CI continuous integration because this is where it needs to be caught. So the pattern is a problem occurred. It was not detected during CI. The immediate thing that you need to trigger is what do I need to add so that that error gets caught the next time during the CI? So adding integration tests, adding unit tests, adding the goal to the build command in this case. I found it a very interesting experience here and I wanted to share that to the group. Okay, we're running out of time. I'd like to give the word to Jake, Chris, and Alyssa. Does one of you three want to ask, say, or comment on anything that was said? I don't have anything, John Mark. Okay, thank you. Oh, I would just echo what you said. It seems like every product is going well and contributors are doing well and I know I can speak for Garage. He's been great. Okay, well done. Okay, thank you very much. It's a pleasure to work with you all. You're making good progress. I should say, but I'm proud of the work that you're doing. Okay, have a nice rest of the day. Everybody continue that way and talk to you next week. Thank you. Bye, everybody.