 And then I will start sharing my screen and then we will get rolling. Okay. Can you see my screen? Yes, sure can. Thank you. Great. All right. Hi everybody. Thank you for joining the Jenkins online meetup. This meetup is about Jenkins in Google Summer of Code 2020. So on this channel, we aim to conduct regular online webinars about all things Jenkins. If you have a Jenkins story, tips and tricks, we love to have you speak about it here. So just drop us a note in the Gitter channel there. And we look forward to hearing your stories. Some housekeeping notes before we begin. Please put your questions in the chat window. I will make sure that all of our speakers will respond to your question throughout the presentation. This session is being recorded. We will share the link on the meetup page later today. And if we can't get to your question or you have questions after the session, feel free to drop a note. Or your questions in the Gitter or the community, community discourse channel. And we will respond to it there. The Jenkins Code of Conduct is fully enforced here. If you're not sure what it is, it's simply being kind and respecting each other. On the agenda today, we will start with covering introduction to GSOC and GSOC Jenkins in GSOC. We will go over project ideas, timeline, project idea, presentations by potential mentors and Q&A to close out. So this event is hosted by Jenkins, GSOC, Org Admins. This year's Org Admins are Jean-Marc, Chris, and myself. So what is Google Summer of Code? Google Summer of Code is a global online program focused at introducing new contributors into the open source software development space. GSOC participants work with an open source organization on a 12-plus-week programming project under the guidance of mentors. This year will be GSOC's 17th year in operation. The program has connected 18,000 new open source contributors from 112 countries with 17,000 mentors. Google Summer of Code has produced an impressive total amount of 40 million lines of code for 746 open source organizations. So Jenkins first began participating in GSOC in 2016. This year will be Jenkins' sixth year participating in the program. We currently have 10 potential mentors with eight project ideas at various difficulty levels. The project ideas can be found in the link there, and if you're interested, previous year's projects can be found in this link below. Our goal is to provide a positive and enjoyable experience for both GSOC contributors and mentors. The work for these projects will provide a sense of challenge yet a rewarding learning experience for both mentors and participants. We intentionally keep our project numbers between five and seven as we want to focus on the quality of the experience rather than the quantity. We work very closely as a community. We do weekly office hours, organized meetups, events, and we stay in close contact via chat and community discourse. The project types that we offer are key initiatives to provide a sense of challenge. We also provide a sense of challenge goals such as configuration as code, plug-in improvements, and Jenkins pipeline just to name a few. So these projects actually do yield a high value to the community in general. So what this means is that your contributions are benefited by Jenkins users as a whole. So Jean-Marc. Yes. Thank you. So we have a lot of projects that were selected last year and that reached a successful end. I'm not going to explain them because today, because we have a lot of other topics that we want to and explain the current projects. Have a look to the history. So the archives browse through it, get ideas, look how they were connected there. Before going to the next slide, I just want to explain just to be sure that everyone understood it. What we call office hours is that we have a meeting every week at a regular cadence where it's just open for at least half an hour and where you just come and either we have some organized topics there, but at least this is the watering hole where you can come to ask questions and see what's going on, where you have an interactive way of dealing. And we have them flipping time zones. So we have one that's more oriented for Asia and the other one more Europe, Asia, Europe Middle East in Africa time zone. Next slide. I thought it was important. The beginning, I didn't know what an office hour was. So here, these are some pictures of last year's or previous year's experiences. One of the things that I find very great is that the successful contributors get invited to the annual DevOps World Conference and have a chance to present their project to the community and interact with a lot of people. Well, this is an interesting reward. And the picture below is, I think, I'm not sure of that. I think this was one of the reunion of the various candidates at the Google campus. I'm not sure at all that this will take place again. Okay. The other one, I think you can continue. I can cover this one. So as mentioned earlier, we do stay very close contact throughout this program. We've set up a dedicated communication channels like GSOC Discourse, GSOC Gitter, GSOC Weekly Office Hours, like Jean-Marc mentioned earlier. These channels are quite active, so feel free to pop in anytime and ask your questions there. All right, so how to apply. So if you go to this link here, it's go all the way up. So this site is really helpful in walking you through the application process and setting correct expectations before the program and actually for the entire program itself. It contains a lot of helpful links to all things Jenkins and GSOC tips and important information to keep in mind during the program. One thing that we want to call out is this project proposal template. The purpose of the template is to discuss your ideas with the community early to solicit feedback from potential mentors so they can help strengthen your proposal before you apply. This template is just a suggestion, you're welcome to use your own template. We also recommend that you don't wait until April to start working on your application, start writing your proposal much sooner. So again, to solicit feedback and encourage potential mentors to help you make a better proposal for yourself for Google. Okay. And then what's important then when when you when you apply choose a Jenkins project. Yeah, that's what it should look like. Yes. And Jean-Marc will go over the project ideas. Yes. So, well, you can have a look to the to the URL that's that's there. Maybe if they say you can click on the link just so that we we see it. So just browsing through it, you will see that there are three categories of projects. And let's go back to the presentation. So we have the overview there. So the the first and more mature project is approved one. That means that the project has been fully qualified is is defined and ready to fly draft projects. It's still ongoing. There are some discussion and refinement going going on. These projects and there's currently only one there. They're fine to apply so you can start already preparing your application application for these kind projects under discussions. There are currently two in that there are still discussions going on on scope feasibility. And you're you're you're invited to join the discussion if you have ideas. But be cautious because we didn't have we don't have mentors for them for sure. Or it's still underway. So listen carefully if you're interested to a project under discussion. So you can move to the next slide. So just emphasizing what is the GSOC timeline. First step that you need to do is carefully look at what are the eligibility requirements for your application. It would be I would be a very sorry story if you do all the work and then realize at the end that you you're not entitled for for it. Read the specification carefully there. It has been a little bit changed as it was mentioned earlier. So read it carefully. Start writing early. Well, most of you have been in higher education so they know the earlier you start the better chances. Your chances are to reach a successful in quality and so don't wait the last day to do and submit draft proposal make them available to the community. Publish them via Gitter or discourse so so how you do that you create a Google document. You prepare it and then you say here this is the first iteration on my draft. Could someone have a look to it make comments and so now this is something important in one. And you'll discover many other differences. One of the things that makes working on open source different than what you used to do at at university or others where generally you keep the work for yourself. You're working on your own. Here everything is open. You share. There is cross-planetization. Even people can take some of your ideas. It's part of these this. Of the process to have these ideas flowing and move and and one builds on on the other. So don't be afraid of it. And saying afraid is. I know it takes some courage to put a work that's not exactly at your quality standards. Openly in the world and say what are people going to think. No, and. Particularly where the Jenkins community and we as org admin. And the mentors have the same attitude. We're there to help and we're a friendly community. And don't be afraid. Don't be shy. We're here to work together. To make this experience successful. So don't be shy. Don't be afraid to. To share that. Discussing and reviewing a document openly is part of the experience is part of working on open source. And one of the things we would like to share. With you. You can start submitting. Your application. So the goal for you is on April 4. April 4 is the moment where you will start. Filling in the form and normally if I remember well, I think it's on the next page. April 19 is a moment where the door closes. Your target now is April 4. Have looked to the timeline. So I've seen a lot of questions. How do we start? We eager your like horses ready to start the race. Start as soon as possible. Understand the subject that you're interested in. Explore it. Get acquainted and explore and get practical experience. On Jenkins on the ecosystem. How the community works. Get familiar also with the pull request methodology and how all this works. This is the very good time. To get these muscles flexed. And to to get experience in that by doing that exercise interacting with people getting ideas. You will build up the knowledge in order. To do a powerful. Submission. For that. So we can move to the next slides. If there are questions, Mark, you will have to. Yeah, John Mark, are you okay if I pop in with questions? Sure. So is it okay if a potential contributor. So a candidate works on something that's unrelated to any project idea just as a way to get experience. Is that okay? Or are they expected to work only on project ideas? I think, well, this is a very good question. So the short answer is yes. So it's a good idea to have experience that you have the global holistic picture of how everything is, is together. Jumping too quickly very deep into the subject might make you miss the global picture. It really depends on what is your experience with the tool. I just heard about it and had one demo, a quick demo. It's very important that you have a good understanding of the various components that you see how it looks like, how you work with it. So at least you should install your own Jenkins instance somewhere on the laptop or whatever. Configure it and have a pipeline for a regular build. So this is one of your projects on it. So this would be the default path for getting it acquainted. Then have a look globally for simple or what's the name for not newcomer, but entry level issues. And so you learn it and even just a documentation update or something like that. And then you have the practical experience of what it is, the get voodoo that's required in order to submit a pull request to have it reviewed and then it's merged so that you at least made a few times the complete circuit. Okay. The last thing I wanted, if you get stuck, if you don't know what I'm talking about or what are these concepts, come to the office hours, ask your questions, you have the asynchronous ways of using the various communication channels we are. Don't stay stuck shy in your corner and why I don't know how to do that and try to find it myself. Ask for help. We're together in this adventure. Thank you very much, John Mark. That was perfect onward. Thank you very much. So you just stopped me my flow if there are other questions. The question was very good. So just what happens afterwards? So you know your goal now is April 4. Start filling in the application. The end of application is April 19. The mentors in Oregon admin for Jenkins are then going to select in the various applications who will join the next step of the adventure and their contributors will be announced on May 20 at that day. So once we reach that, then, well, okay, we rejoice and I'm okay, sorry for the people that were not selected. And there will be other opportunities. The next step is that we we're going to start what's called the community bonding period. It means that you will then get into contact and build the relationship with your mentors and you're going to sell how is this going to work? So there will be quite some meetings and discussions so that you get warmed up. And the actual coding is starting on June 30. And what happens afterwards and how it's organized, you will hear from your mentors and we'll do other sessions to go to there. An important thing is I'm not sure in the submission. I don't think that there is a question there, but generally don't forget to state and discuss what are your availabilities during the summer. I would recommend adding it to the submission form as a note, meaning that if you have obligations during your summer, if you still have end of term papers to write or you're going to get married or whatever important things where you will not be able to focus as you would like on on this, let us know so that we can we can eventually organize and see that the mentors are available or I'm not waiting for you while you're away. So we need to organize this this period. And it's okay to say that, well, no, I have work for university to do and I prefer to stop. You're still welcome at least as contributors to our project and there will be other coaching, but Google summer of code is an important an important thing. So let's move to the project presentations. So this is an overview of the projects we're going to present today. And we're going to walk through each one with the main mentor doing the presentation of his project. So the first one is Chris. So your turn. Okay. So the first project I'm going to talk about is automatic and get cash maintenance. The goal is to review the features available from a relatively wisdom feature from good code good maintenance and identify ways that the Jenkins controller could use these features where implement some similar features to manage your cash copies of get repositories. So what this does is one to end tasks to optimize and get repository data. So that that's our priority. The second is speed up all the commands and get and third to use storage requirements for repository. So it's three problem. Some percent potential features to add the first one. I put a star there because it's like the most important feature register strategy. Schedules includes G C can be graph prefetch lose objects incremental repack and for like more details you can go like to the link above later. And the second feature we can add is one third start for stop fifth unregister skills to study and to improve for this project would be a Java and get and the project difficulty is intermediate. All right. So this Jenkins is incredibly powerful and there's a lot of really cool things to do for it. But one of the struggles that we've had is making sure that all these really interesting things are documented. So this this project works on kind of creating that central documentation resource for being able to access the Jenkins rest and points. So this is kind of modeled after what we do right now on the website. If you ever go to Jenkins.io and look at the pipeline steps that are available on that page and we will be talking about that later. Later. A project idea. You could see that all the things are displayed there. So we this project is kind of doing the same for our different rest. Also, if you install Jenkins, you could there's actually a link and you can see what rest points are available within your specific instance of Jenkins. But the problem is it's a lot of text. And so we need to also be able to. Display that using standards. So that's swagger or open API three. And so the, the, this project is being able to come up with that being able to do that automatic generation. Expose what's available and then potentially maybe even make that available within Jenkins itself. So this is going to be an independent tool, not a Jenkins plugin, but there could also maybe if we, depending on your scope to make changes to Jenkins itself. You might have to look at core. So a lot of it is going to be looking at swagger. The website, looking at how we publish our website stuff. And I think that this is kind of maybe a. Advanced beginner intermediate project because if, especially if we're going to core, but the independent tool, I think is something that can be done by somebody. Fairly easily. Okay. So back to me. This project Jenkins file runner action for get actions. It's, it's not entirely new because like previously we have had a POC project. That there's a similar name. From three years ago. And the goal of this project is to use a new tool called Jenkins file runner to implement a new complete feature versions. Of what we have had before, which is a project guitar. So you can see POC link below. The skills to study when proof are Java, Jenkins, Jenkins file runner, Docker, get actions, configuration and voice to note. So it has been done before. So it won't be like a start from scratch project, which is like a sign point. And to run a strength of new incubating for your action is to find a way in file link there. And three get to be acquainted with Docker and get actions, configurations, which it's a good like asset to gain. And for exposure to basic DevOps concepts. And a project difficulty for this idea is intermediate. Right back again. So similar, how I was talking earlier, we do, if you go to the Jenkins IO site, you can actually see this really amazing list of all the different steps that are available through pipeline. However, some of those steps are a little bit confusing to read, because the way that we generate this is we basically have like a headlight or like a Jenkins list plugin manager. And it just is using exactly what's coming from the source code itself. But sometimes that's not exactly the best to be able to read like for a human. But what you're supposed to do is you're supposed to go in, kind of do the research to figure out maybe how we want to display this information on the page rather than just kind of barfing some things up and then have a chance to improve the layout. So there is some like writing that will be available here. It's not 100% code, but there is some thinking about how things should look on like to be able to help with documentation and also kind of maybe potentially even making those changes to code themselves. So that's a tool that we already have in place and making some improvements to that. So it's kind of beginner and beginner type project. And the plugin installation manager tool improvements project idea is taking a project type of a project that was actually a Google summer of code 2019 project. And that is widely used now throughout Jenkins to manage plugins. Configuration as code. You can specify precise versions of plugins I want and the plugin installation manager tool goes and retrieves them for me, brings them down and installs them. This project idea is that we encourage you as you're considering proposing a plan for this project idea that you look at the open issues, review which things could use improvement where the places where users have had difficulties, what has caused them struggles or challenges, the existing documentation looking for things that are commonly done review chat sessions or Reddit sessions or community dot Jenkins that I am looking for common questions so that you can then use that to shape your project plan with your selection of improvements and your implementation plan for those improvements. So this one is as much about design and definition as it is about implementation. Your smart core. Oh, yes, that's right. Sorry, I should keep working. I can also. No, no, thanks, John Mark. Thank you for the reminder. Yes. So, so in the Jenkins ecosystem. We have Jenkins core and Jenkins core provides a platform on which one or many plugins are installed. Those plugins provide the key capabilities. And that means over the course of the 15 years that Jenkins has been under development. There have been many plugins developed there are over 1800 available plugins from open the open source community right now, and the number of plugins continues to grow. However, for maintainers and for users. They aren't always sure about the condition of a particular plugin. Is it well maintained. Is it actively maintained. How many people are using it. What's their success or failure rate using it those kinds of questions. And this project idea suggests that we would like to have a Google summer of code contributor. Join us in helping to create a plugin health scoring system so that maintainers can see which things are important for them to be doing in order to show that their plugin is well maintained. It also will help users as they say which plugins are better maintained and which may not be as well maintained so they can bias their choices towards plugins that are well maintained and will give them a good experience. Now this is a multi-component project. And there are phases in this project where we know we've got to collect the data with 1800 plugins. There's a lot of data to collect. We need to aggregate the data and combine it in useful ways that will require some data storage some consideration of how do we store the data. Then we need to present it and we have at least two different audiences that need to see the presentation. The maintainers who have one set of needs and the users who may have quite a different set of needs. So collection aggregation presentation and data delivery all part of this project idea. John Mark was there something before we go on to that when John Mark was there something else you wanted to highlight on plugin health scoring. No, besides that this is a project that I'm very fond of. So I've been dreaming of that for some time. It's not a one man's story or one lady's story. There are sub-components in that and so the, you don't need to tackle the whole. There's several stories in there. And in the description you can have a few hints. This is just a summary for it. So the prototyping just, this is why we highlighted these components. Components are typically one thing where people can work quite separately. Love to see that. Oh, that's, that's my turn too. So, well, this is another project that comes from my, my previous years as Jenkins admin or working with that. So Jenkins configuration is coded as a very neat feature that allows to configure Jenkins based on the YAML description. And so there's also the preferred way when you want to work the GitOps way to configure Jenkins. We don't like mouses. End of the joke. The problem is that in certain circumstances, you want to allow the end user to modify the, the, the configuration manually. Because you need to do a test in production or you want to give experimentation freedom to your team. So the reasons where you change the configuration manually, but that means that the, the configuration as codes will drift from the actual one. And so we want to have a tool or we, we need a tool that will identify that the configurations are not in sync anymore. And that if we apply the original one, we're going to lose manual configurations. So it's going to work a little bit like the Terraform plan feature that's going to say before, well, if I apply the original configuration, this and this and this is going to change. And Terraform then says, do you want to continue? We want to identify clearly what are the elements that were manually created or changed or reconfigured so that we have a clear identification of that be able to generate a delta description. So because there you can eventually automate and include, automatically include the drift into the original configuration and merge it. And the other thing is just simply saying the configuration changed. It's not equivalent to the original plan to the original configuration. So whoops, you need to stop. Somebody changed it. And so there are different policies that you can put in place. So it's useful and interesting tool. There are different ways to implement it. So it's currently under discussion. So it's living mainly in my brain. I see how it would like to see it working. I think many things happening in my brain, honestly, but I see how it like it, but it's not defined yet. So there's different ways. So if somebody chooses that project, there would be an important functional description part and say, how could this work? What would be the, how would the user or an admin use the tool? There is an interesting creativity part in implementing that. It should be usable in the pipeline or within the user interface. So it's an interesting project. Now I'm selling it again, but I could have used such a tool in my previous live and on my current Jenkins environment. So this is for that, that presentation. I think we are entering the Q&A parts. Yes. Yes. So during, during the presentation, before we jump to the, to the question, there were several interesting questions that were asked and answered online for the record. And so that people that will listen to the recording, they're going to repeat the questions. So one question was, can we apply to more than one project idea within a single proposal? So the first part is, yes, you can apply to multiple projects, but the answer to the second part of the question is no. So you need to have a separate application for each project. So you have one application per project. John Mark, I think I may have interpreted the question differently than you interpreted it. Okay. If I, if I spin my answer to the question. So I thought what the, what the person was asking is, could I create, submit a proposal which combines multiple project ideas into a single proposal as my proposal. And I think that would be allowed. Yeah, I would be a little surprised because merge. I was thinking, I'd be surprised if multiple project ideas wouldn't be much bigger than the time would allow in the three months that we have for Google summer of code. But I think it would be a valid proposal to say, yes, I think this idea and this idea in combination might be a better story for some reason. So, but, but it would still be the candidate's single proposal. Their proposal is here's my proposal. And their proposal could be potentially a combination of ideas, but, but it's ultimately it's the candidate's proposal. They're not just parroting bats back someone else's idea. Right. Well, yeah, that is a very interesting. Lighting, I don't know the English word for that, but another way to answer the question, I hope we answered the question in some way correctly. So please let us know if this was not correctly answered. The other question. And there were several replies to it was, can experienced professionals also participate to GSOC. Could it be all right to work over weekends only really interested, but new to GSOC and willing to contribute. So, after some trials, because my experience is this comes from the new rules. Chris rightly said that experienced professionals are allowed. If they're new to open source, because one of the goals of Google summer of code is to teach the ways of open source and to encourage people to participate to open source communities. So it is allowed and anonymous attendee very kindly pointed out to the exact documentation within the rules. There and beginning of 2022, we're opening the program up to all newcomers of open source. So it's a broader definition. I invite you to read exactly the eligibility criteria is increased said as long as you're new to open source and satisfy the other eligibility criteria you can apply. No, no, and I think there's something interesting hiding in Chris's answer. Chris I believe you were actually a Google summer of code participant twice right. So you were, you were in the second time, still considered new enough to open source to qualify. So new to open source sound seems like it's relatively flexible right you you really worked on two different years on Google summer of code as a student. I think they changed the rules because like before you can participate one at one time, like they they should allow you to if you have done it like I think in 2020 and 2021. I see okay thank you thanks for the clarification I just, I was so impressed that you were willing to be a mentor this year, and that you've been a student two years previously that's that's quite a great thing thanks for being a mentor. I'm not going to repeat all the conversation in the QA summary of that is that if you knew to open source and professional you can apply, please read the rules from Google for for the details. And the other questions was there. And I think I covered the questions that were asked initially. So, so there was there was one March on mark. Oh, it was the number of hours. Well, the question was, yeah, yeah, experience professional contribute if they don't have 30 to 40 hours a week to give to the project which people who are in a full time job typically do not. And I think the question was, can how many hours is expected of someone who selected to participate in Google Summer of Code. In, in the earlier sessions in 2020 2019 etc. They expected 30 to 40 hours a week, but my understanding was with COVID 19 and 2021, and now in 2022 they've cut that number in half, so that, so that if you're disrupted for this reason or that you can still be successful in Google Summer of Code if you can, on general commit 15 to 20 hours a week to the project over the course of this, the three months. Okay, interesting topic and lesson is I need to read and remember the details more in detail. Can I can actually like take us back to kind of the question that we answered or had before. So, I kind of also want to throw out like the idea that if you have your own idea that is amazing and we really like these are just ideas that we have for you. If you have your own idea that's wonderful. One thing I do suggest is trying to get that proposal written as quickly, like as soon as possible to be able to get it out. You can try to help you find mentors on that maybe even beyond the people on this call outside to be kind of able to help guide you through but if you have your ideas, no problem submitting them just kind of do it early, and we'll try to be able to pair you up with somebody that might know more about the area you're concerned about but yeah I just want to highlight that very excited to hear ideas. Yeah, but this is this is very, very true and yeah, I forgot to mention that any idea is open. And this is a principle of open source, whoever comes with an idea just put it on the table. And we're going to see if we can build something around or get people get traction and get people on it so. I want to emphasize that. Are there other questions, so don't hesitate to put them in the QA window. So don't forget, we have the, oh, there is a question how competitive is Jenkins G shock, according to previous years application, it's a bloodbath. No, you did by how competitive is. No, no, I, I don't know why I see a Roman chariot race with people flying over the place. No, no. Those are the last people that were part of the selection process of last year. Don't take too seriously what I said, Mark. So last year as I was reviewing proposals. I think we received five or six proposals in the area that I was mentoring. And we were there for comparing five or six that was not 500 or 600 that was five or six. It wasn't one. Because it was not hundreds. So, does that give you an indication of the competitiveness at some level yes, each year will be different the previous year. I think I reviewed actually far fewer applications for the topic I was mentoring. So it depends on the number of people applying is to decide how competitive or non competitive it is. And honestly sometimes too it's the actual project as well, like I've seen somewhere that there's maybe three proposals for the same project and then maybe one ID only has like one proposal so it just kind of also depends on that too. I just want to encourage if you think that something is quote unquote popular, not to try to put out your ideas but just as kind of a, another side. And Christian's point on popularity. Many times the reason a project idea is popular is because the community is interested in it. Right, and that that makes us more likely to select it. Yes, very true. So, there's a there's an element of, hey, this. Well, it's a great story to tell. You are a brand new contributor to an open source project and the thing you contributed to in 30 days after its deployment, after its implementation was deployed to 80,000 installations. Right, open source has a great story to tell for you making a difference for people very broadly very quickly. And so, so that that's a fun part of this exercise is you could by making a valuable contribution through Google Summer of Code be very quickly in many places throughout the world. It was a question asked and Chris answer to it but for the people watching the recording I would like just to repeat it. So there was a question about how is time devoted quantified. As in somebody may require some time to do research so would that be accounted. Chris do you want to either repeat your answer or adds more color to it for the audience. Okay, sure. So, I think like for the project of time like counted towards at everything you do for the project so research wise research any research done any, any like things you need to check on for documentation or read up documentation, or study like someone else's repo or code would be counted towards the time spent on the project as well. And, and don't run too far away Chris because you answered the other one and so should we look out for ideas that have been least applied for having a higher chance of success. So, can you repeat the answer Chris. Okay, sure. So I think we are for anyone interested they can potentially apply to more than one project idea based on like what Google allows to do before. And so, but I think the most important thing to consider when applying for a project as a good fit. Sorry, I missed the last, I missed that last phrase that you said could you say that again for me. If there's a good fit. Good fit, good fit. Yeah, sorry I had an audio problem. Yeah, and the other advice I'd give is is take particular care in preparing a good proposal and think of the people that are going to read it. So, by writing your proposal, you're talking to people that you're trying to convince and try to make it to be as, as precise, correct, creative convincing in what you do. What do you say then there is another question here. Oh, is it is Jenkins G so according to previous years application I think we answered that one. Did I miss that. I think we know we address that one we address that one. Right. Okay, so I clicked on done other questions or doubts that we can clarify. Don't forget if you have other questions while you sleep on it and rehash what has been said here. We have the various asynchronous communication channels. The Gitter channel discourse so community Jenkins.io and the office our sessions that we that we organize where you can come back to your to your questions so couple of minutes john john mark I'd propose be even more precise. Tomorrow, john mark will be hosting office hours about. It's about 21 hours from now right roughly on the Jenkins calendar is at 20 hours from now so office hours are coming and they're coming tomorrow. There will be the Africa Europe in the Middle East session that I'll be. I'll be hosting so why are you very good at calculating the our difference. Okay, any other questions for today. Lisa. Yes, I think we can slowly conclude does somebody from the panel want to add something. I want to say that I'm, I'm eager and excited to have you on board interested in looking forward to start this adventure is summer adventure together and build something interesting so looking forward to it. And so on this slide here. It's some useful information or links to help you get your questions answered and if you know you don't find what you need, just reaches out via getter we're very active there so throw us your questions there. And if there's no other questions, I guess we just want to thank you for your interest in Jenkins G sock. We look forward to receiving your proposals. Recording will be available within the next 24 hours for your review as if you need to see it separately. Thank you everybody.