 So, hello, welcome to JSoc office hours. After a long break, we continue our regular office hours. So last official office hours was on July 22nd, after that we had a few retrospective meetings, which we didn't put in this agenda because they were separate meeting notes. And now we return back with focus on JSoc 2021. We have several students and past JSoc participants on the call. And yeah, before we start, I would like to just quickly summarize what is the current state. So we finished JSoc 2020. There are a few open indication items left, publishing the results, the blog posts, et cetera. But overall, JSoc 2020 is over. And yeah, thanks to the participant. Now we focus on JSoc 2021. We intend to participate at the JNTC project. At the same time, we are in an early planning stage. So we still need to define our admin team. We need to define mentors teams. We need to create project ideas. So what we have on our website at the moment is just a few initial project ideas, basically what we wrote over from the previous year. The ideas which we still have interest in and which haven't been watched on JSoc 2020. And there will be more ideas in the future. So if you are mentor interested in the project or if you want to submit a new project idea, let us know. We can keep extending this list. So it's just an initial ending. And over the next few months, we will have much more details on the website. This year, JSoc will be slightly different from the previous years. So if you have seen the timeline, you can see that now there are two coding cycles. So JSoc is basically shorter than it used to be in previous years. It means that when we define the project, some project ideas, we will have to take it into account. And also there will be some changes in the initial phases, but largely the JSoc format remains the same as before. So there will be still an application phase where every student is welcome to reach out to the projects, discuss project ideas, application routes. Then once students submit the applications, we will have application review, which will happen internally within their organization. And after working with the other mentors and with Google, we will announce a final list of projects. It will happen on May 17th. So a bit later than it used to be before. And the community bonding will be over on June 7th. So basically, there will be still three weeks of community bonding as before. And yeah, there will be two coding phases. Both coding phases are approximately one month. So instead of three months of coding, basically you have two months of coding. The rest remains the same as previous years. Okay, so that's what I wanted to tell about the plans and changes. Again, right now, we are looking for participants, including co-ordinates, mentors and students, but we can start discussions now. And if you have any specific topics to discuss, if you have any questions, let's just discuss them so that we can start addressing these comments. And before that, do we have any potential mentors on the call or just potential students? I will probably be a potential mentor this time. Okay, so yeah, for you, it's a good time to think what would be a project you would be interested in terms of mentorship, in terms of project ideas. And yeah, we can discuss it in the chat. Also, there are guidelines about posing project ideas. So you can start exploring this area. By the way, what is the project interesting to you or the area? So actually, I was looking at the project ideas. I think remote monitoring looks somewhat interesting, maybe. So I think yeah, let's see, maybe I can come up with a few ideas also. So in previous years, we had from 20 to 30 project ideas this year. Let's see how many we have in total. But this list is definitely expected to grow. Okay. So and from potential students, are there any questions, any topics you would like to discuss on questions specific to projects? Yeah, hello. Hello, everyone. Yeah, actually, I was, I went through the project ideas. And one of the project caught my attention that plugin installation manager tool. Like I went through that. And for that, I saw the requirements like what, what skills I need. So I was not that comfortable in Java. So I went through the like I'm, I'm learning Java at the moment, but I'm like now comfortable with it. But there was a mention of Java configuration as a code g g cast kinder. Yeah, like the how the Jenkins Docker image and configuration as code work in this case to study and improve section fourth one, the fourth point. Yeah. So like, I wanted like an heads up like, can you suggest me from where I should like learn about this things? I actually I saw a talk on this, there was a talk by Nicholas Deluf on, on pragma or something, like at pragma conference on YouTube, I went through that. But like, it is something which I'm not that comfortable at the moment, but like, do you have any suggestion or issues or anything like which will make me familiar with this topic? Because I think this is a very good project like package management. I like, I understand the importance of it. And I also went through the like theory of package management, but not yet that comfortable, but I'm going through it. So just wanted in like reference or something to get more on this. I went through this. Yeah. So you can start from documentation. We have some documentation for configuration as code plugin. And we also have a lot of demos specifying particular topics. So here you can find demos. And yeah, there is a lot of plugins. Usually when you start with this topic, my recommendation would be to just start from creating your Jenkins instance, maybe trying to configure it for your project. And then to move this configuration to configuration as code. So you could follow the guidelines. I hear, for example, there is documentation about features, configuration expert, which describes how to export configuration from existing instance. So once you create your instance, you can just try to convert to configuration as code using these guidelines, using Docker image so that it's also specialized. Here you can find this information, how the Docker images operate. And if you need any specific demos, there is also, for example, yeah, there are multiple repositories which follow approximately the same pattern. I will just show you my repository. Demo Jenkins configuration as code. So this repository basically shows how to configure everything with Docker, JCask. So you can just follow the example here. Okay, thank you. Yeah. So I will put some links to the meeting notes. Any other questions? Actually, I have one more question. Just like not much of a question, but like what's your suggestion on that thing? I was like setting up my own Jenkins instance. But like I didn't want to, what I should say, install a lot of softwares and all that. So what I did was I tried with the Jenkins Docker image. And there was like to work with Jenkins plugin installation manager. There was one reference guide about how to quick, like how to start a quick start section. There were huge, like all the points were mentioned, clone the project, run the test. There are several different lists of plugin, all those things were mentioned in the projects website page. So I was like, I was just wanted to ask, like, should I go with the Docker image? Like, should I try running tests and like trying this tool with Docker image or with the Jenkins instance? Like I began with the Docker image, but I'm like not that much comfortable with Docker. So what would you prefer? Like, what would you suggest? What should I do in that? Like, should I go with a local instance or with Docker, Docker file, Docker image? So in this case, Docker is rather an implementation detail. You can use the tool without Docker and you can connect it to a local Jenkins instance. So personally, I would recommend to explore Docker, because Docker is foundation technology, which is good to know and which is widely used at the moment. And Docker is also required for this project also, right? For plugin and solution manager tool. So it really depends on what would be your final proposal, because here we offer a project idea. So basically it's just our vision of what could be done and what would be the main tasks and priorities, but we don't define a project. It's student applicants who define what would they do. They submit a proposal. We make the decision on that. So why Docker was there? So yeah, you can see that Docker is mentioned multiple times, because one of the main objectives for this project in 2020 was to integrate it into the official Docker images. You can see that this project is currently in the droughts, because the description still needs to be updated. Current stated that we already have it inside the Docker image. So if you go to Jenkins CI Docker, you can see that the tool is over again by the there. Just a second, that is plugin management. Sorry, it's in the documentation. Just let me see the number. Okay, so for Princeton and plugins, you can see that plugin installation manager is already in preview here. So the first step is done, but there are still issues we discovered during the evaluation. And also there are other use cases where the tool could be integrated. So it still remains relevant. At the same time, what would be the particular percentage of Docker work? It's here to be seen and discussed in the proposal. Okay, all right. Thank you. Thank you too. So yeah, you can definitely play with it without Docker. There is a lot of things which could be done without Docker. So if you go to plugin installation manager tool, for example, there is a number of open issues. Actually, not that many at the moment. But yeah, there are some effects which need to be fixed. There are also some enhancements which could be done. So you can play this that without even touching the Docker. And if you come up with a proposal, which doesn't involve Docker and just improves the tool on debates with other technologies, I think it would be doable. Okay. Okay, I'll try. Okay. I'll see. Let's see. Yeah. So we had a joint configuration that's called SIG meeting today. And we discussed this tool a bit because the rest of the effects which impact adoption. And also we still have a problem of having multiple tools. So this is GSOC 2019 project. It was created by Natasha Stepa, one of our students, and then it was improved over time. But we still have the main issue because this project was created to replace other plugin management tools. We have replaced in the Docker image, but there are also many other plugin managers in Jenkins. And we still need to keep replacing them. And it's also something you could play with. Okay. So like our basic main goal of this project is like, as far as I like, if I try to simplify the whole like in crux, our main aim is to create a tool. For example, a package, basically a plugin manager, which will replace all kinds of every other plugin manager, which exists at the moment in Jenkins to install plugins, right? Okay. And in practice, of course, there are different obstacles which could prevent using this tool everywhere. But at least some of your suggestions could be replaced even now. For example, I'm an engineer of Jenkins file runner. It's basically fast mode for Jenkins. You can execute Jenkins pipeline in the container, and then this container shuts down. And here I also have a task for adopting plugin installation manager. There is definitely a cool request for that. So this is one of the examples. It's not finished, but it basically replaces the internal plugin management logic by plugin installation manager library. And you can see that the logic in the tool is quite short because it just supports a few use cases. But instead of that, the idea that here you would get full featured plugin manager. Same for the use cases, you can find a lot of plugin management code which could be improved. Okay. I'll go through them then. Thank you. It may be so you can probably go a bit back. So if you go to 2019, there are also project ideas. And here you can find the original problem statement where this tool was created. So it's here. At that point, we were doing project ideas in Google Doc, which also worked fine. So here you can find, for example, a list of existing implementations. And you can just go through these implementations, but your custom word package is still there. It hasn't been switched to the tool. Jenkins server green. Yeah, this project is deprecated at the moment. So it's probably not the most important thing. Jenkins file runner is here. Also other implementations, which is still around. So you can explore the original scope and the original problem, which could be additional source of information for you. At least it would help to understand why this tool exists and why you would like to adopt it. Sure then. I'll go through them. Thank you. Thank you. Okay, so any other questions or comments? How do we do this meeting? Basically, we hold it while there are questions. If there are no questions, we basically close the meeting earlier so that everybody gets more time. If there is no questions, again, we are just starting. And yeah, since we don't have other mentors on the call, we won't be discussing the project set up. But yeah, I guess we will just keep working on that and still promise. So if you haven't yet joined the million, please do so because we will be doing announcements once there. And yeah, we will go to the developer million queries to assume to facilitate project ideas. Also, if you're looking for more project ideas, so this is just the list of what we moved. But you can find more project ideas, for example, for 2020 on four other years. Many ideas haven't been published for 2021, but they're still relevant. So for example, there are some ideas for Jenkins, for Jenkins X. Not all of these projects have been completed during the previous phases. And even if they go completed, you may find some ways to extend that. So for example, if you're interested to work on plugable storage, last year we finished external fingerprint storage. But there is still a big scope of different stories which we would need to deliver. Just a second. Plugable storage. So for example, you can just navigate through pages and find these stories and problems which could be potentially a project idea, even if it's not listed at the moment. And if you have any idea of what you would like to work on personally, just numbering it up in the Gitter channel and we can discuss what we could do with it. Because yeah, if there is an idea, if there is an student, we can ask around, maybe we can find mentors for this project idea. And yeah, original project ideas are definitely our preference in the Jenkins organization. Once again, I'll go again to about the automatic specification generator for Jenkins Recipe. So I read about the idea. I've gone through SAGAR and OPANI period docs, but the project talks about the automation of the specification generator. So at one place I saw the documentation, there was a SAGAR documentation on the SAGAR hub. But someone commented over there that it needs to be automated. So yeah, so right now I don't really have any idea how we can do the automation of that. So and the next point I'll sort of do is definitely something to explore. Also, just an additional sort of ideas for you. This year we published the public Jenkins roadmap. So here you can find wider stories and initiatives on which the Jenkins community is working on. So here you can see that there are some items in preview, so which have been delivered at least partially. Also there are items which are being currently worked on and items which we want to handle in the near future or at some point. So if you're looking for a project idea, you could definitely take a look at these columns. So near to you and future, because there you could make a proposal for your project. Also some items in preview and currently they could also be extended. You can find a particular area to work on. So you can just take a look at this page and if you see something interesting to you and something which could fit the GSOC timeframe and GSOC, basically project type because GSOC is just about coding. Then you can make a proposal for project radius on the roadmap and to ensure that we could find mentors and interested stakeholders. Thank you for that. I haven't gone through this, but my question was about this specifically about the specification generator. Okay. Yeah, sorry, 42. So it's in 2021, right? Okay, specification generator. Sorry, that was probably the answer. What a question. So here again, the idea remained the same as in the previous year. So we would like to have generic specification for REST API or for a subset of REST API. For this project idea, you can find discussions in the mailing list because last year we had students who were making proposals or we were bringing them a topic for initial discussion. So you can find some additional sorts of inspiration just by going through the discussion. So for example, here we can check this thread as an example. This is probably not the ideal one. There are just a few messages, but there are more threads which could help you. Here we can try to find them later. So just start by investigating REST APIs. If you have existing Jenkins instance, you can play this thread or you can just play, for example, with CI Jenkins IO. You cannot because our REST API is restricted. So most likely you won't be able to really call the endpoints or some of the endpoints accessible here. So API is blocked here. Maybe just on there. No, it doesn't work. But you can find another Jenkins instance which is public and which exposes API. And you can really start writing simple code, for example, extension, etc., which could help this process in common stories. Okay. So opening API basically would be your good starting point. Also for some code, you can see discussion links. You can also see how other things work. For example, there is plugins here. But yeah, there are some components which already generate some data from Jenkins. So for example, if you go to configuration as code plugin, there are two features. One is schema generation. Another one is documentation generation. And both of these features actually use the same indexing approach. They analyze code and analyze extensions and generate the documentation. So for example, here JSON schema. So you can explore the code inside, which could be a good source information for you. Just a second. Sorry if the answer is too abstract, but it's probably an area to look into. And again, for example, next week, if you're interested, we can make a deeper dive, because everybody including me need to restore context. Mm-hmm. Anything else I could help with? Yeah, sure. I'll go through it. Also, have you already checked out Swagger Hub or whatever it's called these days? Yeah, I have explored Swagger Hub and open API specification, that is some kind of product idea, but yeah, for the other thing, I'll take it. Okay, that's good. And also, Swagger Hub is paid now. Swagger Hub is paid version now. So are we planning to use Swagger Hub or like something like Swagger Hub should be generated and every time like REST API something is changed and automatically documentation should be generated. Is that agenda for this? It can be an agenda, because again, it's up to a student to submit the proposal. So for example, you explore this project, you define what would be interesting to you and what would be important. You discuss it with mentors and after that, you come up with project scope definition. For example, if you propose integration with Swagger Hub, if all mentors agree, why not? It's definitely something which could be useful. But while working on that, you still need to keep it in account the project duration, because yeah, two months is not that long and not everything can be delivered in two months. In this project, there will be likely a lot of foundation work, just a bit basic functionality running. So if you're able to also deliver integration with Swagger Hub, why not? Okay. Anything else for today? Looks like not. So then thanks to everyone for your participation. I mean, we will keep working and preparing to the project. Most likely we'll do official kickoff in December. But meanwhile, you're welcome to start exploring the projects or to propose your own project so that you have more information and start preparing for the next year. And so I'm not 100% sure whether we will have a meeting next week. But if there are any questions, please spring up them in the chat. So we have Jenkins, GSOGuitar. This chat is open 24-7. So if you have any questions, just drop them there. And if there is a chance, we will definitely host the meeting next week. And even if needed, we can have even more meetings. So it's quite unlikely in this early stage of the project. Thanks, Paul. And the video will be available by tomorrow. So I will stop the recording and see you next week.