 Hello, welcome for this second Office Hour for Ghoul Summer of Code, it is today the 10th of February, two o'clock UTC, and we'll try to make the most to finish on time. We failed to start on time because we had some link issues and needed to set up a few things but we'll finish by respect for everybody on time in half an hour. There's a first meeting on this time zone and it will thus be a quite open discussion. So we have around the table here several mentors, I am the org admin for the Ghoul Summer of Code for Jenkins supervising the general process and making it all work together. The purpose of this meeting is to be able to meet the mentors, ask whatever questions clarifications you have and bring whatever topic you want clarifications on. So first a little presentation, we first have Mark Waite who is joining in from the west of the United States, so very early bird. We have and he's mentor for several proposed projects. We have Dhrash who is also mentor I believe and he's joining in from the Indian time zone and we have Chris who is also a mentor and part of the org admin team and he's located in the Chinese time zone. I am located in Brussels, Belgium so the middle of Europe between the United States and Asia. So we had a proposal, an agenda proposal here so before we start digging into the things I have a very general question is do you have general questions doubts clarifications or comments to do? Don't hesitate to open your mic and we hear between friends. So let's go. I think it's quite impressive to talk like that so maybe the questions will appear afterwards. The general suggestion before we start is I recommend that you listen to the recording of the Pacific or Asia office hour that we hold in the middle of the night for Europe. They're also very interesting things that are shared there so we try to share the knowledge transfer on both channels. Don't hesitate to listen to that in the notes of the previous meeting. We added also here some useful links and information. Don't forget to look at them and get ideas and probably also questions coming from the reading of these documents. So do we have a question? I see that the Raj is saying so can we also discuss here the project that haven't been selected yet but are under discussion for now? The short answer is yes we can discuss that. The longer question is will I am following this project quite closely and it's a project that is near to my heart on that. So I'm able to answer to that subject Raj. Well and it may be worth clarifying that there may be a misperception there that it's worth noting a project has not been selected. What happens is candidates submit their proposals for the project. So there are all of these projects are possible ideas that you might choose as a potential contributor to submit as your proposal. And what you do is you have to turn our idea into a real proposal and converting our idea into a real proposal means creating a plan for it and what the steps you think would be and how it will work. So there are many, many steps to get from any one of these ideas to a real proposal that is your proposal. John Mark, go ahead. For me that's one of those. It's not a simple, any contributor picks up a project idea and it's ready to go. The idea with Google Summer of Code is each person who is submitting their application brings their proposal and outlines it. They, they've thought about what steps should be taken, which changes should be made they've got they've done some experiments themselves, and then they bring a project proposal that is their own proposal. Yeah, very, very true and very to the point. It's, it's a two way process. It started by the mentors who started to describe a project idea and the participants or contributors can provide additional ideas, questions or, or it's a work that we do together, especially once you have shown your interest or get interested to one or the other topic. Then we can start the process of discussing with the mentors or in the, in the project group where several communication channels are set up. Where you can, you can have a mailing list, a Gitter is generally the easiest way to interact with with the project teams or participants being mentors. And so on. So don't hesitate to propose ideas or, or say, well, this could be, this is how I understand the task. This is how I would, I would propose that as an addition. So Very good point, Mark. Any other general question about mythology or Oh, yeah, since, since dirage asked for that topic first, I'd say let's, let's spend some time on that one already, John Mark, I think you can, you can give some Overview, it's not been discussed before in any other session. So this would be a good thing to have recorded as these are the concepts here, the ideas, etc. Right. Okay. So first thing, I tend to be enthusiastic. So please, this is not a sales pitch. So I'm not selling the project. This, this is a sales pitch and we John Mark is trying to sell you on why his choice is the best, at least mine will be when I talk about my ideas. Okay. Let's Here, let's do it in an honest way. So the, the health score idea is that I've, I've been working with Jenkins administrators and being have been in debt duty. For a while. And When you want to install a plugin. You need to do that judgment. That's it. What is the quality of the, the plugin? What is the kind of risk that I take? Is it a well maintained plugin? Is it trustworthy? Or will it tear down my, my Jenkins instance because it has memory leak or, or whatever. So there is all this reflection. What makes a good plugin or not? And it's also a guideline for plugin maintainer. Meaning that, well, here, here are the things to watch. This is a well kept plugin. And this is a plugin like a garden that you didn't tend correctly and you have wild, wild grasses all over the place. And so it's also a hint for plugin maintainers what needs to be done. There's several ideas and some work being done on trying to qualify what is a good plugin. And this is a very interesting subject to think about. And we're very interested to hear the opinions of participants to that. So there is this work. Another very important work is let's say that we decide that this is a measurable automatic that you can automate criteria that shows that the plugin is a good quality and you can use it without too much worries. So these criteria we want to try them out. So there is. So we want to try out some proof of concepts. How do you automate the validation? How can you automate, for instance, are the dependencies maintained and up to date? How many open issues are opened? And we want to run these probes on the 1800 plus plugins that we have so that we see what is the general distribution on the plugin herd that we have to see. Is this criteria good and where are we going to put the levels? So summarize first. What do we want to measure? Then we need to do some POCs and further of implementing these probes. And then the third step is we need to think how are we going to propose these results to the public? How are we going to modify? Because we tend to go in the direction of providing this information on the plugin update site. And what will be the most efficient way to present these information in a useful way? So this for administrator. And then you have also how to show these results to maintainers. So that they also see, well, okay, I should maybe do some house cleaning there and do some maintenance on that. So to summarize three main access and three main work topics where there are small items that we can work. So it's not a huge, huge thing that will do as a model it. The first one is work on probes to define the probes and validate and describe them. Testing the probes and observing what is the statistical distribution of those probes and so that we verify that the initial assumptions are correct. Third work domain is presenting the results of that. So it's a very complete project. There is some preparation work to be done. There are some quick short-lived work items that can grow into complete probes. And then there is also the display. So I believe it's a very rich project where there's lots to be done and we're not standing in front of a big mountain and say, where am I going to start with it? So, Mark, was there a good summary of it? I think that was great. Very good. Yes. Now, now I think we should ask a question now to Diraj. Diraj did that. Did John Mark's answers cause you to have any additional questions? Yes. So thanks a lot for this really, really great description because you explained with the help of examples as well. So that puts things into picture. And so the three steps you mentioned as documented by Mark as well, I have a question about what are the attributes of a well-maintained plugin? That is the first one, like which attributes do we want to keep going Diraj? Yeah. So, Diraj has background. Okay, go ahead. So the question is for the attributes, I was thinking that maybe we can refer the contributing to the open source document by Mark. So is it a good place to look for these attributes in order to determine the well-maintained plugin? That's one valid source. It's certainly not the only valid source, but it is a valid source of some data points we might consider. John Mark, your comments? Yeah, indeed. So there are various data sources. There's also some work a couple of people have already started. I think it's important that we start consolidating that and get the various sources together. And because it's part of the things I like, I would like to use that in order that we start explaining and writing some documents to help the people. It's not just saying, well, this is not achieved or this is under the expected level, but how do you get there? How can you do that? So there are multiple facets to it. Come back to your comment, Diraj, there are multiple sources contributing to open source is one. It's the modernization workshop too. There's a lot of very important insight in there. Good point, Diraj. And there may also be other hints in things like the Jenkins Health Advisor from CloudBees has some interesting pointers in it. Conversations in the Jenkins developer mailing list. Many other locations where we could find hints about what could or could not be done. Yeah. Diraj, do you have other questions or is somebody else in the audience having questions or interest in this? I do have some questions, but I don't think this would be the right place because my questions are more into the implementation part of it. So I think it would be better to ask it on data channel. Yeah, and as I see there's a lot of interest, especially from you Diraj, and we try to get a few other participants in there. We need to get the pot cooking and brewing and the ideas start to come in and we'll work together on that one. But I see that at least you and probably other people start to see where we are. Okay, it's very interesting because participants can have an impact on that and contribute even small pieces, but it's a very interesting project and that would really help the community to improve and use in a better way Jenkins. So this said Mark, because we're going to run out of time. This was what I feared that I would get a little bit too enthusiastic about that subject, but it was worth giving. There are other subjects where during the last session there were quite some answers given to the automatic specification generator for the REST API. This is one that I would like to move ahead because I've been struggling with REST documentation so really would like so I if you're interested in that project, listen to the recording of last week. Chris gave some good answers and explanations about the Jenkins file runner. So as Chris is on the call, if somebody has questions on that subject, please go ahead. So I wonder the things that we didn't get to in the last call was, we didn't get to plug in health score you've reviewed that we also didn't get to get cash management and I was going to shamelessly ask if you'd be willing to let me spend a few minutes on John Mark on the get cash management topic Chris has very nicely put the hyperlink there and if you'll just click that hyperlink. If you're if you're willing to let me spend some time on that project idea. Yep. Go ahead. If you can, if you can make this make the text bigger for us. My eyes don't read that well. So the work with control plus being used with the screen sharing it doesn't work. Oh, that's all right. It'll be fine as it's no no worry. I'll use perfect that. Oops, are you still there. We are. Yes, thanks. And that's perfect. That's great. I had a I had a power failure. I hear the alarms in the neighborhood. Okay, Mark, go ahead. So, so Jenkins, one of its primary roles is to check out source code from repositories and get that source code then to be operated on by build processes by compilation by execution of tests. And one of the things that it needs to do frequently is to use a get a copy of that repository and then it will do additional work on that repository other copies. That means sometimes Jenkins has caches of get repositories and caches of get repositories are helpful, because they reduce the amount of data transfer that has to come from the central get server to the Jenkins controller. That's helpful. However, the, the implementers of get, did exactly the right thing and that they optimized get for short term operations, and accepted that the user would periodically do some maintenance activities like garbage collect the repository, or or do other removed stale branches remove stale tags, all operations that human beings when they interact with their get repository can do pretty easily. But Jenkins as an automation server does not have a facility right now that will automatically clean up caches cached get repositories properly. So we've had cases where CI Jenkins.io, our primary Jenkins server for the Jenkins project has had slower than necessary repository caches, because they hadn't been well maintained. It had been created a year ago and just continually updated and no one had ever run the maintenance operations. This project idea suggests, we need a facility in Jenkins that will allow it to automatically and periodically perform cash maintenance. So that's the idea. We're almost out of time so I think I should stop there unless there are questions from people about the idea. Great. So, if you if you'd like to learn more about it there's a command called get maintenance. That's included in recent versions of get. And you can read the man page about get maintenance, and you can see what it offers as techniques that are already built into command line get to do these kinds of things. That's it for me. Thanks, John Mark. Right. Okay, Mark, sorry to have pushed you a little bit, trying to finish on on time here. So a last advice or tip I would give to everybody. So take on this. Write down some questions and reach out to us either through community dot Jenkins dot IO, or via the Gitter channels. And we'll take, will we going to take particular to make a particular effort to answer these questions publicly. So please avoid pinging us directly as as much as I would like to help everybody. This does not serve the community. Every question is worthwhile and is useful to everybody joining or contemplating to join the GSOC program. So don't hesitate to ask your questions publicly. There is no shame to ask a question. Every question is is good and will take the time and especially I take a lot of it may it's very important to me and I want to answer that as good as I can publicly so that everybody can benefit from these answers. Now, it's half of the hour. Thank you very much for participating to this call to listen in and to the questions that have been asked. We're going to have the next meeting in this time slot that I think is good for India time zone. We're going to have it in two weeks. We're alternating every week between what I call the Pacific or Asia office hour and the European Middle East Africa office hour. Thank you very much for attending waiting for your questions either live or on Gitter or on the discourse on community Jenkins.