 joining. Got it. And thank you for joining everybody from different zones. Is it recording? Yes, it definitely is. John Mark, I can confirm it's recording. Okay, good. So good evening. Good day. Good morning, everybody. Thank you for joining this edition of the Google Summer of Code office hour. Office hour means that we meet every two weeks or every week to just discuss and answer whatever question you have related to the Google Summer of Code program managed by the Jenkins. So let's quickly walk through the agenda. The first thing and I can immediately jump in it. So I'm happy and proud to say that the Jenkins project has been officially accepted as part of the Google Summer of Code 2022 as a mentoring organization. So that means that all the preparation work that we started in February can now continue and go on and we can even go higher in the revolutions and the RPM starts kicking the engine to get going. So the first item we'll do is open up on any questions that potential contributors have. I've seen some conversation yesterdays on the Gitter channel, so this will be open. Don't forget that if you want to use this channel as efficiently as possible, you can always submit your questions directly in this document as comments or mention your question in the Gitter channel and say I would like this discussed in depth during the office hour. I want to add and to remind of what are the upcoming dates, what is the schedule in front of us, what are the important milestone. I would like to do at the end refresh or answer any questions that would still be open or doubts related to how to proceed to create your submission and how to do it practically. There was a very good demo done last week on the recording, but we'll come back to that. So opening to the floor to whoever is here, what are your questions? My first question is, it is possible to bring a new ideas or these ideas fixed for the 2022 Google summer, of course. The answer to the questions are two nos. So or yes, depends, depends, shouldn't do too much fun about that. So the first one is it's not closed at all. Okay. We still have time. We are not limited to the existing project ideas that are registered. You can add yours and there are some indication that I can eventually walk you through or remind you how to do it described in the various documents. I read it just now. There is some .r file to create and whatever. It is clarified there, but the first question was it is now or not? No, you still can go on. The end date, I think further than that, would not go is when all the submissions are registered. So this is end April. Now, so you have one month to create a project, discuss it, have it give it substance, prepare your submission and then have it discussed by the community. So it's not too late and yes, go ahead. If you're you're you can enter and you're you meet the requirements. Let's do it. Okay, great. There are other questions. I have a doubt regarding the automatic cash in maintenance thing. So basically, yeah, I've gone through the entire, you know, get maintenance thing on the get SCM website. Okay. And then after that, I thought we are going to implement it via the CLI. Okay. But then Mark stated it in the chat that we won't be using the CLI version will be have to we'll have to be coding it. Okay. So I am not sure like what is the exact architecture? How are we going to proceed with it? What are the things which are, you know, the user requirements that that thing I'm having a bit like I'm a bit confused about it. Good question. John Mark, you okay if I answer? Yeah, sure. I just wanted to. Okay. So so my my assumption is that we would use command line get to perform the operations because it's the most reliable and it's the reference implementation for all getter operations in the get plugin. So if we need to do a garbage collection, we would call get GC. If we need to do a a repack, we might make a call to do repack specifically if we need to do a fetch, we would call command line gets get fetch. Now, does that address your fundamental question who should cash or have I missed something? Yeah, but then you stated that you know, we are we have to support sent OS seven and then open to 18. So that so that basically I think that get version was something we just lost you to muting who should cash but maybe I can answer to your question, even making assumptions. Go ahead. I didn't get you. Can you repeat? So so we lost your sound you you asked the question you asked seemed to be Hey, since we can't use the get we since we need to support old versions of command line get. Yeah, yeah, as we actually you stated that we have to support sent OS open to 18, right, when to work in 18. So basically that so and those operating systems by default, it doesn't support get maintenance. Okay. So regarding that, I haven't have an issue like how are we going to implement that? Are we going to use like alternatives for that or how are we going to most of the operations that are implemented in get to dot 30 and later as get maintenance are actually can be expressed with more fundamental get commands in the earlier versions of get. So what has to be done is identify which maintenance operations we want to do and how we express those maintenance operations as fundamental get commands that will work with a specific those specific get versions. So for example, get maintenance to schedule GC can be done just by a Jenkins conceptually by a Jenkins Cron schedule or a scheduled task that performs calls the command get GC. So because of that, we can support those old, old environments, even though they don't provide the get maintenance command, they do provide the other baseline commands. And one of the important explorations is to be assured that we get what we want out of calling get GC. So does does that answer your question, Krushakesh? So basically, it's like get maintenance is built over, you know, the previous you know, functionalities of get, and we are going to use those functionalities only to build the exact get maintenance. Correct. It's that in order to do the maintenance operations, we use foundational get commands that have been there for a very long time. Now, part of the exploration may discover that command line get 1.8, which is still bundled with CentOS 7 is so old, it doesn't have certain operations. And in that case, then we would have to show the user on the UI, this operation is not available because the get version you're using can't do it. We've had that with sub modules, for instance, we've had that with some other things where the plugin has to tell the user, sorry, I can't do that because command line get on the version you've chosen to use doesn't have the capability. And that was from my side also one point, because maybe it should be created some switch, which one version you want to use, because we use for some special reason, a really old version of the get. And after them, I will be really not happy when the checkout plugin doesn't work anymore. Correct. And so the get plugin actually already has logic inside of it that detects the version of command line get that's available to it. And it can do logic based on that saying, Hey, this version is new enough, I can use these new modern commands, or it's older, I have to do some ugly work around, or I have to change and tell the user I can't do this work at all because your command line get version is too old. Martin, was that sort of the idea you were suggesting? Yeah, or just make it configurable that when you start this checkout function that you want to use the cache or not, but default, yes, fine. But when you doesn't want it, then you just use the old one things. Yeah. And this particular idea is actually not so much about checkout. And we do have a concept of different get tools in Jenkins. So we can make a get tool that is version specific. So yeah, good suggestion. Thank you. So Hrushakesh, did we address your question or is there more you would like to ask? Thank you, Mark. That has addressed my question. You had also a question. There was another question related to the get plugin and the get client plugin. Can you suggest me where to start exploring from? Because I'm not getting a starter class. There are so many classes. And I'm trying my level best to keep searching, but then I'm not finding anything to start from. And so when you say start from, you mean in terms of a possible implementation? No, because I've been discussing and I understand the question the following way is and it's also a general question. You discover a new plugin and you want to understand its logic and to see where is the head? Where's the tail and where are the legs? And so where do you start? Where do you start exploring the code of a plugin? So my general hint is look at the tests, put some breakpoints and look what happens. But maybe you or Adrian have other tips. So I was actually taking Hrushakesh's question more as how do I explore the user experience? So, okay, Hrushakesh, can you help us understand there? It was actually based on how exactly I start, like the main function from where everything starts, like the main class. Exploring the Java code. Yeah, so then exploring the Java code, at least for me, I tend to do it in a debugger. I tend to do it by running the tests. I tend to, but pretty quickly, I get bored with that and have to go using it interactively to see what the features are at the user level. So I'm not sure I have much good advice to offer you other than if you want to look inside the code, that's debugger and watch what it does when you make calls. Stepping through the code. Right. Now, you had asked a question in Gitter just 10 or 12 hours ago that was, I thought, a user question and there I can point you to some good videos and to some good introductory materials, some tutorials that will let you see how users use it. Now, that's different than a code, right? That won't introduce you to the core code in the plugin, but it will introduce you to the user concepts. And for me, those are probably as valuable for a new person starting as anything about what's inside that code. Okay, Mark, I think I'll go through those links if you share it and then try that way of exploring the Git plugin. Good. For me, the exploration of using it and realizing, oh, it does this and it thinks like that and it works like this has been the most helpful for me personally. Do you want to add more question, Hushikesh? I'm sorry, I butchered the pronunciation of the name, so I apologize for that. But do you have other questions related? That those were my questions. Okay, great. I see that Vihan raises hand. Vihan, you can go ahead. Yes. So I had a question regarding the scope of the project of pipeline step documentation generator improvements. So from what I understand of the project is the pipeline step generator repo is fetching the documentation for the pipelines and it is feeding it to genkins.io. Correct. And what this project wants us to do is we want to improve how we treat that data which is fetched and not how we fetch the data, right? Correct. You understood exactly. Is there anything about the Groovy code also? Because we have many of the Groovy code which should be documented to, I mean in our company, sorry. In this case, no, it's intentionally selecting from pipeline Java code and it's the help from Java code. Vihan, back to your question. Continue, please. Yeah, so whatever changes we would do is how we would treat that data and basically represent that in a much better way that the user can need it easily. Correct. Right. So we believe that many of the problems there are related to presentation as to how does the poor user consume this material? Now, there's plenty of, we need a lot more material, but with the current presentation, it has many weaknesses that are identified in that idea. Okay. So regarding that, the question I had was like, for example, we make some changes to how we present the data. So won't that look odd on the genkins.io website because that is only the pipelines that documentation has been changed the way we present the data, but the others are still in the similar format. Basically, I was thinking of trying to put some visual aids for the user for them to follow the links to some other pages and not just keep the data on the same page. So will that disturb the behavior of the whole website, the flow of the whole website? It won't be uniform. Good question. I don't think it will disturb because the pipeline step doc generator continues to generate ASCII doc. It will generate a doc and that ASCII doc, it's perfectly valid for it to contain links. And if you're generating ASCII doc and they link to other things, that seems like a very helpful, helpful way to do it. And if we discover by the work on this that we should also do similar improvements elsewhere on the genkins.io site, that's a great outcome. That's if you propose an idea or a propose a plan that is making the following changes and improvements. And we realize, oh, those are improvements we want everywhere. We will happily borrow that and put them in more places. So we would love to have you find some find a have a plan that gives us something dramatically better there and embarrasses us about the rest of how bad other things are good for good result then. Yeah, actually, so what I was doing was like, I was browsing the documentation for various different technologies frameworks. And I was like finding which one was more visually appealing and which one I found to be like easier to comprehend. So one such experience for me was studying Django. So I started in a project which was like from scratch. And I found the documentation to be really helpful. And like most of the people who would help you would directly point you out of the documentation because it was very easy to read. And so yeah, this is how I'm planning it out. And perhaps I hope that I would come up with a nice idea for this generator as well. Thank you. I think I think that's a great that's a very good approach. Did we cover all your questions, Vian? Yes, thank you. Thank you so much. We can move on. There are other questions. Yes, Mark. I would like to talk about automatic specification generator for Jenkins REST API. And this is my first office hour. And I would like to know much about this problem statement from you guys first of all. Okay, so so is what what I think would help then is a general overview. And and let's talk about what what the general overview is. So Jenkins has a REST API that is derived from simple annotations that developers add to their plugin source code to declare that something should be a REST API endpoint. It's got all sorts of automatically naturally created REST API endpoints. And you can see those as you start your own Jenkins. And at the bottom right hand corner of the page, you'll see a hyperlink REST API. And you you can get some very fast exploration of what are the REST APIs. Every time you create something in Jenkins, there's a REST API link down at the bottom of the page to give you help to help you use that REST API. So there's a lot of REST API documentation already. But what there isn't is a formal description, and especially not a formal description in open API format of those REST APIs. And and that lack of a formal description means there's it's also more difficult for people to consume the REST API, because there are things they may not discover simply because they don't know where to navigate in the Jenkins pages. So a formal description of the REST API would have to be extracted from Jenkins and its plugins. It's somewhat similar to the pipeline step documentation generator that was described earlier to in response to Vihon's request is that what that thing does is it looks at all the Jenkins plugins and extracts pipeline documentation from them. What this would be doing is look at all the Jenkins plugins and extract the REST API definition from them. Okay, after, yeah, that's pretty much clear. After extracting those APIs, we would be making use of those for documentation in Swagger, right? Right, yeah, in open API, yeah. So Swagger, and if I understand correctly, Swagger and open API are synons of each other? Yes. Yes, yes, correct. Yeah, I actually have a little hands on experience on microservices. Usually in microservices, we have something called controller, service helper, these all packages, right? But when I have gone through our code in Jenkins core, it's not the case. So do you have any suggestions on how to start with our code in Jenkins? Because this is completely new to me. Yeah. Yeah, so I think my answer is that's when you'll have to explore. I would not expect it. Jenkins is a mature application. Mature is a polite way of saying that its source code was created 15 years ago and it has evolved over 15 years. So it was well before the concept of microservices, right? And so you're certainly correct. It won't look like current microservice based REST APIs. However, the crucial thing here is not to make it look like current microservices, but rather to document and describe what is there so that people can use it more effectively. And when I say document, the awkward part here is many people think document means right documentation. In this case, it's really not right documentation. It's extract the definitions of the APIs that are already there. And that has to be a programming task. Yes, yes. I have actually gone through Java documents. We have this website, right? Stapler. I have gone through Java docs page and I started inspecting in that those URLs. Yeah. When we inspect on UI, we get the URLs, right? And I have gone through the code and I can relate the packages whatever are there in the Jenkins core and in the UI. Are these APIs, are we going to document Swagger or are there anything different? I think the answer there is yes. We would want an API document that we would want a Swagger slash open API description of all the REST APIs that Jenkins can provide with its set of plugins loaded. So I'm not sure I'm answering your question, Bharu. Could you give me more clarification? Probably, I need to do more homework before actually asking this question. I'll come up for the next topic and shoot you with more questions. But yeah, this actually made me a bit clear. Morning I was so bewildered. I was like, am I going to do this or not? I explored and explored and I said, okay, this is not my thing probably. But right now it gave me a bit of hope at least. It sounds like you're on the right path. Go ahead. Oh yeah, that's great to hear. Actually, regarding this GCOS proposal, my question is when you start a problem statement, you'll start with one solution in your mind. I mean to say, before writing a proposal, I should have some idea, right? Okay, this is what I'm going to do. This is my way of approach. But especially when you start and when you're in the middle of something, some things may deviate. Something or some other thing will come up in the middle. So then it is not going to be what we have started at first, right? Maybe it won't be, as we have mentioned in the proposal. So how would it be? It is fine to go. Excellent question. Yes, it is fine. So to give a very specific example, last year we defined and accepted a project plan to do some particular improvements to the get plugin. And we realized roughly halfway into it that we had to change the definition. And it was perfectly fine. We agreed with, discussed, did the modifications and implemented the modified version. So yes, we realized that project plans do change. The research upfront helps us reduce the volume of project change, right? And many times the projects complete exactly as expected. And that says we did really good research. But if something surprises us during the execution of the project, we have full flexibility to make changes as needed. Just to position the first part, the research. So as Mark stated, the research is subject to change because you discover things in this modern way of developing. The document that you're going to write is very important for us to see, did you understand the problem that we're trying to solve? Do you own it? Do you know what are the different pieces of it? Do you come with something positive and creative to answer it? So it's just one step in the complete building process of the project. But there is an intermediate step where, as we don't have place or room for every candidate, we're going to use this first analysis and study to select the people that will continue together with us in this adventure. Yeah, thank you both actually. Coming to your question, Mark, I mean, did you understand the problem statement completely? So currently, there are some parts from the problem statement which I am not clear right now. So going on, it may take some days to completely understand and come up with a solution. Actually, time answers everything as far as I know. So what my question is, what are the other ways of talking to mentors or like whoever can help us? Are those only GSoc hours and guitar channel or do we have any other calls even? Mark, so I'm going to jump in here because it introduces the next step of it. So these discussion forms, as you mentioned, discourse, getter, these meetings are unstructured communication channels. And this can help you refine your ideas. The very important step that you should start now is start creating a draft, a work document or you can make it any form. And you're going to ask the community, can you please look at what I wrote? Can you comment on it? And this is also the way open source works. And this is the complete purpose of Google Summer of Code is to teach the ways of open source. And a very important element of that is that we work publicly. And that means you're going to write your ideas and share them and propose them for discussion. Somebody will come with corrections or did you think about that? Or it's this process that you should start as early as possible. Is that clear? Yes, Mark, yeah. It's clear. Your both names are actually with Mark and Mark. So John Mark is Belgian based. Mark Wade is based in North America. And my first name is with the two. So Jean-Marc is the way it's pronounced is a composite first name. Yes, yes. So you have it. So you have Mark and you have Jean-Marc. In that case, I write always wrong name to you. Sorry for this. No problem. Here, we're slowly getting out of time. I have one last question. So go ahead. If you, I just like to, is that a problem for the others if we continue for a couple of more minutes? No, no problem. Okay. So go ahead. If people have to drop. Thank you all so much. So I, yesterday I have actually raised a PR on generate migration. I actually started off contributing, you know, small one by one probably. And I have seen a video on Hacktoberfest, which was phenomenal. I actually loved that video. And I have seen there are, there can be done something more. It is actually now there's something called adoption, right? So can we go on and contribute simultaneously along with these writing the proposal? And this would add some benefit to the proposal, right? To the proposal, to the community, to the product. So if, if you have the time for, please do it. And we're there to help you. I'm going to rephrase your question. So, and I'm going to cheat rephrasing your question. I think what you asked is, may I adopt the plugin? And the answer, yes, the answer to that question is an unequivocal. Yes. Now, in the case of this specific example, it's not immediately clear to me how adopting a plugin will help you. But it's certainly in on this specific example, but it will certainly help you understand how the community interacts. It will help you understand what it means to release a version of a plugin to merge pull requests. Those are all good things to learn. So, so no dispute that adopting a plugin, I'm not sure how the REST API specification generator will directly be assisted by that. So, so just to be sure I set your expectations fairly, I love the idea of adopting a plugin. It's a great technique to learn. It's a great way to contribute and to experience for yourself what it means to do coding in an open source project. Oh, wow. Wonderful. Mark, I am going to start with, you know, running Jenkins in my locally so that I would understand exactly right for my problem statement to start with automatic specification generator for Jenkins. Good. This is generally the path that we recommend. It was also described in some documents. So first run a local Jenkins instance, get familiar with it, start study the problem statement, explore and explore the product and the various plugins and start to interact with the community. So you need to be familiar with PRs, who is doing what, how it all works together. And this is all this this learning process you are in. And they should now work during the month of April. Yeah. Thank you. And that's all I have. Okay. I'm just going to cover the two last points. I'm sorry if there are still open questions. We'll have to push them for another session because I'm respectful of everybody's time here. The things that I want to remind everybody is so the timeline. So what is coming next is described in the link I'm showing here in the screen share. The next important so the next phase where and we're started started March seven is that the contributors start to discuss the application's ideas with the mentoring organization. This is what we're doing currently. As we said during the conversation before this is done by the interactive channels. This course so community dot Jenkins dot IO get a channel. These meetings here and a very important mean friend is start writing ideas start to flesh out the is the correct expression. Your project what you want to do and make the community interact with it. Get ideas get correction for that. This is really what you should focus on the deadline for that is where the intermediate that I said from April 4th. This is when you start submitting your applications on the Google system to declare your your application. And normally if I remember well the deadline for ending the application so the final deadline is somewhere in April. If I remember well I didn't write it here but in my memory is not good anymore but in the link is 19 April 19 April okay wonderful good. So this is important start working and interact with the community on your proposal. There was so how do you do the application proposal. This was extensively discussed in last week's office our edition. Mark made a demo we completely out of time here. We can revisit it's the next EMEA or Europe Asia office hour in two weeks or watch carefully the recording from the March 4th edition where Mark made the demonstration. A strong reminder don't try to edit the template and it's no need to request editing request for it so you need to duplicate the template. Oh yeah that's for me. No but it happens to everybody but it's just a reminder so you need to copy and duplicate you need to discover how the tool works if you're not familiar. Are there questions on those two last topics because we will have to. Thanks Christian for joining at this hour of the night or the early morning. And taking so careful and well made notes so that I could concentrate on the conversation. Thank you thank you very much for your help. I thank you all for attending this session making it interestingly interactive and wish you good luck and good work and meet you then on Gitter or other channels. So I'm going to stop the recording now. Thank you all.