 Okay, hi everyone. Welcome to the GSOC meeting. Today we have a special session about the Plugin installation manager project idea. I'm going to share my screen. Okay, just a really quick introduction. So we have a project idea for this year, which is related to improving Plugin installation manager. This is the continuation of the previous work we've been working in the JINX community, including GSOC 2019, when Natasha Stopa actually created this plugin, and there were a lot of improvements. And now we have basically a wide open project idea, which suggests doing some improvements in the tool. And if you go through the tool, you can also find that there is quite a number of open issues there, including various feature requests, bug reports, etc. So in our proposal, we basically offered students to take a look at the backlog, to find the areas which are interesting for them, including UX, backend, whatever, and then come up with a proposal. So yeah, this is the context. And we have several students reaching out. Any questions and topics related to this proposal? Yeah, I think we can start. So I would like to go first, if anyone has issues. So yeah, Oleg, you mentioned one thing about the bomb, the bill of material and the infrastructure about that. What do you think about that? You also mentioned that we'll have to, I think, make some changes in the Jenkins infrastructure to expose that or host that, the metadata of that. But can we discuss what are your views? So just to clarify why it's important, it's one of the tickets in the store. So currently, there are multiple ways to provide versions, but generally you end up with such a definition where you specify what plugin to install and what version to install. And the problem that if you define version, you would have to maintain it somehow. So there are tools which automatically update versions. For example, why do we use dependable in the Jenkins project? We also use updated CLA created by Oleg Verna. And yeah, there are other projects like that. But at the moment, there is no project which would support this demo format. There is a project which supports plugins 60, so text format, but not this one. And the idea was that, okay, why do users have to manage these plugins at all? Because we have another component we created, which is called Jenkins Bomb. So basically, it's a hill of materials for plugins, which includes a set of plugins for different Jenkins LCS baselines. So we don't provide it for weakness, only for LCS. And therefore, basically, we have regular releases, which provide a set of plugins, which has been cross-tested using standard Jenkins tools, including plugin compatibility test, etc. And how it looks for users, basically, they get a list of versions of something like 100 plugins by now. And these versions, at least they get some confidence that they're compatible with each other. So it's not like it's fully guaranteed compatibility, because we don't use, for example, a certain set harness, WebUITS, and other bits, but it still provides some level of confidence. And the idea is, what if users use these versions? So that, for example, if you do not specify a version here, and if you have an additional setting like version source, Jenkins Bomb version, whatever, just another definition that plugin installation manager would go check versions of these two materials, and use these versions as default ones, if nothing to specify. So that's the idea. What I mentioned in the ticket while we had a discussion, and your proposal is that if you want to read these versions, you will need to read them from somewhere, because currently, it's maybe, so it means that if you go to Repo-Jink and Sayo, it's basically a Jenkins architecture instance, provided by JFrog, and which is used by the entire Jenkins project at the moment. So here you can find this bomb, and basically it will be pomexml, if you're familiar with this medium, which you can read from there as a developer. And when we refer to these builds of materials now, maybe in definitions, we actually read from there, I think. This was a bad idea. Well, you can find it there, but basically it's just pomexml file with the result versions, and this unwrapped dependency list, because there is some inheritance there, so you get a plain pomexml, something like, let's say that, but here is all the versions attached. So this is what Jenkins Buildflow uses. If you want to use it in a plugin installation manager, you would need to somehow retrieve this file, or to maybe read it from a different source, and hence I mentioned that it might require some changes in the Jenkins infrastructure, because it's really a question of how we want to serve this file. So like how you mentioned from whatever, I think you mentioned jfile, a website where you went and bomb.a, you searched it now. There was one website which you went, Jane Fry, I think, some website which you visited, and directly you could see the pomexml of bomb over there. Yes, currently you can see it here. Yeah, what's the name of this repo.jnk instead? Okay, you can find an exact link if you want, but it's there, just a second, let's take a look. So it's your Jenkins to bomb. Okay, so I mean, don't they provide any kind of API or something like updates.jnk instead? It's a JSON metadata kind of thing. So like, don't they provide anything like that? In the form of what you would use for this, of course, you can just download the file from there. Okay, but it has all those limitations. So if you just want to download it, it's possible. But yeah, so what you can get right now, well, unless you find something I'm not aware of, is so that your Jenkins to bomb. There's no tools because I'm looking in the wrong repository, I guess. Okay, yeah, it should be not in public, it should be in a really good So we'll have Yeah, if you want to cover Jenkins tools, bomb, so you can find the baseline switch, for example, this is the last LTS and here, for example, version 27 is the latest version. So you'll get this up. We'll just put it to the top. Like if I hard code the others, then it'll be like very hard, like every time a new bomb release comes out, we'll have to update it. So kind of we'll have to think something like what is then like what changes in the infrastructure like, which is interesting, I mean, creating something like, yeah, if you're fine with this file, you can theoretically adjust the model from that URL. So yeah, for some issues, we should be discussed, for example, in the factory, because that factory is really designed as a built on the user service. Okay, so it means that we don't provide the same level of availability as for other services, well, we don't guarantee everything, thanks to Gcrop, it works perfectly, but and yeah, so you would also have to parse this format, etc. So there are some hidden obstacles. If you go to updates, Jenkins Ion, so here you can find basically the site. So it's, yeah, this Jenkins Ion search download. So this is basically our download site where you can find the plugins, the way you can find the work files. This is the mirror, and this is highly available infrastructure. So if you just post bombs there in some format, then you would be able to retrieve for this metadata and serve it quite reliably. And also, yeah, there is the update centers. So for example, let's just go to this Jenkins Ion again, and here, for example, other configuration files being solved. So yeah, I'm just, now we have a bit different front end there. So there is example of one of metadata files we are serving, and actually there are a lot more different items. So here you can see that there is, for example, we serve information about updates, also information about recent releases, plugin versions, etc., which can be retrieved. And then there is information for Jenkins plugin site, including documentation, etc. So it's also referenced somewhere from this list. So yeah, this is the metadata you include, and actually we serve more metadata. But yeah, this is part of our infrastructure. It's what Jenkins uses. So it would be fine for plugin installation manager to use it as well. But in such case, you would need to do updates if you feel it's important. So like just adding, I mean, communicating with other members who are involved in the community and taking their feedback, what they think on it. I mean, just adding one more thing, one more option of BOM will not affect or harm or break anything. But it is part of further discussions, like what you suggested to include BOM as an option over there. That will be like, then we can really use the environment variable, which we have set for the tool. And from there on, we can access the versions of the plugins, right? I think that would be so. Yeah, there are multiple ways how you could do that. Yeah, one of, yeah, and just for example, it's not something I would press for, and it's up to you. Then we can just pick something like version sources, for example, BOM, but yeah, just provide an example. So it's not something like you would like to follow baseline 2.227 version 27. You could do something like that, and then you could say that, for example, you plug in this list in BOM. So here you can just get here, for example, for this bucket branch source, the same for Docker, same for script security, you could just keep it like that. And for pipeline step cpi, so unless you're ready, you could keep the form of something like that. You have to keep jumping and plug in because it's not included in the BOM. So again, it's just an example of how it would look like. Yeah, like how the user can input, like give the plugin.aml, where the processing part. Yeah, so it's up to you to design how to look right. If you do it before the final proposal, it's great. If you don't, it can be discussed later. Okay, I'll try like, I don't play. Okay, I'll see. I'll see. You're active, right? Like you don't have any, as like you'll be like if I post my link again, you'll be, you've brought the feedback as soon as possible because today is the deadline and I didn't want to like extend this thing to the last day, but I don't know why it happened. Yeah, so my recommendation would be to, of course, submit the user. My recommendation is to submit your proposal as soon as possible. Yeah, I cannot guarantee that I will be able to review anything today because they have meetings starting in one hour and a half. Yeah, but yeah, it's up to you. Understand. Thanks for that. Yeah, one more thing. I have discussed this before as well, but I just want to make this thing clear. Like there was one time I mentioned about the Jenkins folder. Did you remember that issue where we like we provide a feature to the user? Yeah, add support for generating a new plugin file based on the current Jenkins folder. So like this is the issue and I have very vaguely like discussed or mentioned whatever I want to do in the proposal. Yeah, this and not this one. Yeah, it's actually the previous issue and just adding the sample here. Oh yeah, that's great. Yeah, so and that's something that I recommend to everyone. If you see any discussions coming from public, you can just discuss it there because this is the project. Like that way everyone will be updated with what's happening. Okay, so something quite weird. Okay, so you're asking about the generating list of plugins from the folder fields, right? Yeah, so that folder is basically some directory that where we downloaded our plugins or like, I think you did mention this in one GSOC office or but I tried to find it, but couldn't find it on YouTube. Something happened. I don't know, some office or this yeah, yeah, regarding this one only. So what what is the Jenkins folder like the plugins directory or I you did mention this but I forgot it somehow. Okay, let's take a look. Thank you. I'm not sure whether I have something, but most likely I do. So let's see what is that. So it's basically packaging definition, I believe. So there is no Jenkins workspace. Well, let's see what you have in camp. No, it's not something. I'm just trying to find Jenkins, which I wouldn't be able to use to discuss because deploy Jenkins. So like, are you looking for a Jenkins instance where you can find Jenkins folder? Okay, yeah, well, you found it. So just whatever I think from development, it's two years ago, doesn't matter. So he's Jenkins home. So it's basically a root directory of what the Jenkins exposes. And the other we have multiple folders including one called plugins. So yeah, here you can see this example. Okay. So we don't need to find something else. Okay, let's just go to whatever development folders. Like what will be there in the plugins. .hqr.jpa files, like those files will be there? Actually, it depends because Jenkins supports the both four ones. Okay. So usually there will be JPA files, but in some conditions there might be JPA ones as well. So like, just those things will be there? No, like other than that, nothing is like I mean, just those plugins will be there. No, in that in the plugins folder, like other than that, there will be not something which I have. I might be there. Just looking for an example. Okay. Let's just do it here to demo. What I'm going to do then. Auto completion works different here. Okay. So we create a work directory. Okay. So something quite good. So I'm just going to start. Oh yeah, I'm starting a new version of Jenkins. We don't have any other reasonable terminal on this laptop. So I'll just open another console. Okay. So you can see the Jenkins instances starting. So we will install a few plugins. So while we wait, are there any questions specifically about this project idea? Well, I know that Vandan and Agita have different questions, but yeah, just in case I'm missing something. Well, I'm just trying to understand what exactly is the purpose, what things we are trying to add into this project in terms of plugins. Like you were explaining something about bomb, which is an existing dependency, I guess, because there's a bomb.xml already existing. So we need to like, what is the, in short, if you can give a one-liner like what exactly is the use of this project, it's like doing an installation or something like what it does. So it's not a plugin. It's a CLI tool, which allows management plugins for Jenkins, but without starting Jenkins. So basically you can do it in a CLI mode without starting Jenkins with your configurations. Then you just get the plugins you need. Is it clear or not? Yeah, somewhat. I'll just go through the documentation. I think you have shared links there. So I'll just go through that again. And I think there's already an existing code in which, on top of which, you are trying to add more enhancements to this project, right? Yeah, that's correct. And like just want to clarify for that participant thing, like you're saying, for participating, we have to submit a new project or we can be part of an existing projects, which are posted on the homepage of Jenkins. Okay, we can discuss it because it's a wider project. Okay, it's still started anyway. So we have a number of project ideas. Being these are project ideas. So we encourage students to export them and to come up with their own project proposals. And this project proposal might be based on one of these ideas or might not. It depends on you. So you can come up with a completely original proposal. And then we'll review it, decide whether it's feasible for the company, whether it's feasible technically, etc. And then decide which projects we accept. So it's a long explanation. It's a short explanation of one process. But yeah, you can submit any application related Jenkins. Okay, so basically to participate, it's like necessary to submit a new project. That's what you're trying to say, right? Yeah, so the application guidance. So if you go to the documentation, information, application guidance for students, this is the same, more or less the same guy as you would get from the JSOF work site. But there is some additional information. Additional, not a student or like. Sorry? I'm a working professional, not a student. Okay, then you can only be a student, you can be only a mentor. And as a mentor, you can join any project. Is it a deadline or something like to join as a mentor, like you have to submit or like you have to raise a pull request or something? For mentors, there is no strict deadline. So mentors can join the project at any pace. If you're interested, my recommendation would be to reach out to the community as soon as possible, because today is a deadline for student applications. And yeah, after this, we will start the proposals and form and remember things. Okay, so when just two more questions. So how do like, suppose I go to the projects, how do I like contact the relevant people, which are part of that project? Like is there any slack channel for each project, which is ongoing? Or like, how is there any other communication channel? So yeah, for that, you can see that on many pages of Jenkins, you have a connect button on the right, and sometimes in the description. So here, for example, we could go to project ideas. You can just plug in a solution manager. We discussed it. So here you can see that there is a description and also contact links. For example, we use platform C as a umbrella specialist tool for this project. So here you can see the mailing list, the data chart, also regular meetings are organized. And yeah, so you can use these links in order to establish a contact with the community. Okay, got it. So as a mentor, we will be able to raise full requests, like we will be able to like contribute as well, right, apart from guiding the students. Yeah, that's perfectly fine. And what we can contribute to Jenkins is an open source project. There is no restrictions from contributing. So if you go to plugin installation manager tool, there should be no contributing guidance in this repository. We created the key forms, maybe not, but yeah. So basically you can just submit full requests. Okay, sure, got it. Thanks. So with a place for any repository in Jenkins, you can just create the submissions. Okay, you can see that there is ongoing installation. So let's see what we currently have in the directory. Sorry that everything is so slow. That's why I use another computer for development. Okay, and you can see the layout of this directory. So you can see that installation is still going. But here you can see that there is a number of GPI files. These GPI files are basically to represent the plugin packages. And then there are also folders. So these folders basically provide unpacked plugins. It's needed for better performance on startup. And also class loading happens from basically these folders. So when you hear, you can see that there is basically an exposed plugin, including some manifest, metadata, and the JAR files, if needed. JAR files is basically, well, it's just Java binaries themselves. The rest is metadata. For example, this is a plugin manifest from which we extract information about versions, dependencies, et cetera. I see. So what Tim has in that issue, what Tim raised, he wanted the tool to go through this folder and generate whatever is in that folder and print it out in the three formats, which I have mentioned. So that was the... So basically, take this folder, scan it, and generate a plugin installation manager configuration file representing the state of this folder. So just read all plugins which are bundled, extract the versions, and information and provide this metadata. So it's not something impossible because again, you'll go to any plugin. There is meta information, there is manifest. From this manifest, you can discover group ID, which is needed for some configurations. You can just cover artifact ID. Well, it's just the older name, but you also see you get the plugin ID or short name is always a plugin ID. Plus, there are other things you could use, but basically you just process archives and extract this manifest file or parse that and generate the resultant file. And the main purpose of this like is to pass it as a configuration or it likes support, I would say, for the task purpose, right? Yeah. So basically, it's a feature for configuration export. So you use this plugin in order to extract the actual list of plugins on your instance. And then, yeah, then once it's converted, you can start using the Jenkins migration as code, or basically the same plugin installation manager, but in the installation mode. One more question, like where like this, is this folder, I mean, what I should say, constant and not constant, I mean specified, like its location is specified for every like every installation, like every instance at every computer, like wherever it is installed Jenkins. So it's the plugin folder. Is its location, I mean, constant or it varies depending upon where the user has installed his instance? Okay, so it depends on how you use Jenkins, because if you use classic Jenkins, it's more or less fixed is Jenkins home and there is plugin directory. But if you use Jenkins in other flavors, for example, Jenkins fellow runner, it's a fast capability for Jenkins, then this directory may be located somewhere else. So yeah, my recommendation would be to prioritize it. So like for the starting purpose, like for the for the initial state, I should like ask the user to provide me the location of this folder that'll be good way or no, okay, okay. So basically, it's also a question of parameters you would need to pass. Yeah, definitely. So yeah, okay, sorry, you go ahead. So my recommendation is probably a bit too early to the current stage, but you can just play for these existing Jenkins instances and explore how plugin directories are generated. Because yeah, this is a most common example. But for example, we discussed instead of GPI files, there might be HPI files in some cases. Then in some cases, these files actually represent the directories. So also GPI would be GPI, but it would be directory instead of the archive. Because at some point, somebody decided that it could be a better option for performance because you don't need the process of these files. So there are many such cases we can discuss later. Sure. But yeah, so this is the basic format. I was also like, yeah, please. Also, there is an opportunity to disable plugins. So you can add additional metadata file, for example, gdk2.gpi.disabled. And then this plugin will be disabled and not really installed. So these cases is something you will need to process. I was like, I was saying that I was also looking at the demos of jcask, like how I can use or how the output from this tool's ML file can be used for. So I was also exploring about jcask. And I'm currently doing that in this time. So yeah, definitely looking forward to this. And I also came across this one open pull request. Still, the pull request is still open for the locking part. It's titled as adlogging. And I'm also targeting that. I don't think there's much progress in that. I mean, it has been dominant for some time. Okay, we can just go to the code again. So plugin installation manager tool. So if you look into the code, so we have two components. One is CV and the other one is library. Our interesting code is in the library at the moment. And there, for example, we have implementation. And there is plugin manager Java. It's main class. It's quite big. But yeah, you can. So there is a lot of opportunities for refactoring, actually. But here, for example, if you talk about plugin, you can see that the main... So a lot of loading happens through system out. So basically, you print directly to CD out. And it's not a good practice for system logging. Because there are existing frameworks and APIs for that. And Jenkins historically, we use Java utility logging. So it's a part of a standard Java. So it's available basically using distribution. And you can use that as an example. I think Natasha had opened a pull request on that. Like logger. Like she created something, but in pull request, in the plugin installation manager only, there's a pull request like open. Yeah. So I mean, what happened? Like why it was not completed? I mean, what were the issues? If you can tell me, like I can avoid those issues. Yeah, that's a good question. So what happened? What I could say is that it just wasn't finished. So some messages are quite straightforward. They can be converted. Some discussion because, for example, there is optional info. Natasha generates a single entry to log it. It's quite possible, though it's probably not the best practice, but it's possible. Why didn't we merge it? That's a good question. Most likely because of the timing, it was quite late in the JSOG please. And now it was actually quite earlier, but it has never been finished. And we haven't merged it yet in JSOG. But then we had merged conflicts and finally now we finished that. So it would be nice to get it over the line. It's a relatively straightforward. So it's about to repact it into a big chunk of code. But if you want it to do, you can actually take this pull request and analyze that. So you can take a look. Yeah, so there are some differences resolving the match conflict might not be that trivial, but it's possible. True. Like, yeah, I can definitely look into that. I do. And she also mentioned something in her comment, like something about levels, like level.fine and all. I mean, she said that some messages were out, like some messages were printed somewhere not because of the levels and some issues in that. So it's one of the features of system logging because you can define which login level you use for 24-level states. And then depending on how logging receivers or listeners are implemented, this message will be either printed or not. Because login receivers might become pretty different. It might be console output, file output, writing to whatever external logging story. And you can stop what login levels that they process, what login classes they process. And basically here in this interface, you say, for example, this message is a warning or this message is a severe error or this message is a formation. So just for user information, or you can add other fine-grained levels like debug, etc. And then based on this level, this message will be either printed or not. So basically when you work on this change, you would need to determine what is the kind of this message and to set appropriate level. I was like going to do that, like under evaluate what are the levels of the messages. But yeah, for sure. So usually it's quite straightforward. There are some disagreements even in the Jenkins code. So sometimes we change login level for particular messages. It's just a question of setting something initial. And the default behavior to do that remain related to the same while we use levels up to info. Because these levels are printed by default if user doesn't configure the login system. Yeah, like exactly. Like one must like one has to decide initially and then depending upon the behavior or the receivable of the like depending on the feedback, it can modify later on. But yeah, for sure. First we'll have to select one level. Okay. And yeah, like I had these questions for now. And I think the some of the issues that I have selected are pretty straightforward. For example, this logging one and these are like, but some are a little bit complex in my opinion. I don't know how like Pico CLI, I have got the reference of your Jenkins file runner. Like you have implemented that. You have migrated that to Pico CLI for marks 4j. So I've got that reference. I'll like definitely make a POC of like, I'll definitely create a workflow of how I'll, what options should I start with for the PR. So I'm working on that for the migration and the logging one is a little bit simple. I mean, do you have any suggestions for me to like for the proposal or anything like that, which you would like to say or like yeah. And any advice, like that's it. I don't have any questions. So your proposal is quite reasonable. In terms of the scope, I mean, yeah, there are multiple tasks. But yeah, all the tasks have value for users of this tool. So I think it's okay. And it's a review later by the mentors. So again, you have a lot of opportunities to improve that. For example, to think how you configure this, what would be the formats, for example, for the scope, etc. Yeah, the scope of issues is generally fine. Okay, thank you. Thank you. So that's all, that's what I had for, that's what the reason I asked for this meeting, but I'm so clear. That's okay. And if we can continue. So if there are other questions, we can discuss them. I have maybe the other 15 minutes, maybe more if needed. So just to finish questions about mentoring, are there any other topics you would like to discuss or clarify? So most of these projects are like Java-specific projects, or it is like a mix of all text, like it can be a Node.js or anything. It depends on the project. So this here would say that the majority of the projects are about Java. So you can see that there are skills to study and improve, and you can find the skills just here. Okay. Okay, yeah. In project and logic topics. But here Jenkins, the system is around GVM. So basically you can pick whatever GVM language you would like to use. And here are some of the projects that are not started in Java at all. Governments are just written in Golan, and there are many other components in different languages. Okay, thank you. Welcome. Hey Oleg, how are you? Is it okay if this gets a more semantic version in plugin for Jenkins now? Yeah, let's discuss that. Okay. So actually it's more about the proposal than the project. So first thing that is still in the draft phase, so I mean that won't be a problem rate. I'm asking this again. I know that is there. And I've pasted the link to my proposal in the chat. So if you could please, I have a few questions. And really you did review it once. And I think I've updated my document based on all the reviews from you, Gareth, and Sliden. There are some comments that now that I have to submit this proposal on the GSoft page, what is better that I should keep the comments as it is or remove them or how it should be. I don't provide strong advice on that. Because actually the proposals themselves are still reviewed by the organization. So it will be the same list of mentors. Okay, so I think it's better to keep it that way. Yes. Then maybe it's aware of the previous panel. Yes, so basically what I would recommend are the two approaches. So firstly summarize the discussion in the proposal. So for example, if you came to an agreement with a mentor or if you processed the feedback, processed the edit, for example, some bits in your proposal, or maybe if you decided not to follow the suggestion or whatever just the commentant. Let's say you considered options in the bottom and whatever putting feedback, then you can resolve this comment because basically the discussion was closed and it's addressed in the project proposal. After that, there is no need to keep this comment. But if you leave it as a kind of open discussion, then yeah. That's a separate topic. Got it. So I agreed with Gareth on the comment below and did the needful. So like I come in there that I have included in the sixth point and then I can close the discussion. Is that what you're saying? Okay. And with respect to the deployment part of the plugin, there it says that I've already done and I'm still not sure that like how can I change it in the proposal to, yeah, I accept that. But how do I reflect it? And this one? Yeah. So down below, there is the stage where I've written. So it's a stage one. So if you go to stage three, I've written about deployment part. And I had a word with Sladen also with respect to deployment. He also says that I just too early to think about it. But what do I write in the proposal there? Okay. So yeah, let's define the deployment of what? Because if you might be talking about Jenkins release process or if you might be talking about how you would deploy it in pipeline. Because here you say that it's semantic version of plugin for Jenkins. So my understanding that you always run from within Jenkins, right? Right. Okay. So here you can take a look right at Jenkins file and make the plugin ready to use in Jenkins. So I understand what is this path which is basically Jenkins pipeline compatibility. But I'm not sure what is this path, right? Okay. So I might have put it wrong. What I meant there was like somehow I would make the plugin compatible with the pipeline. So suppose some other project which is using this pipeline. And this project is more like an add-on thing, right? So if you have a project and you want an automated semantic versioning, then you install this plugin. So it should be like sitting inside the Jenkins pipeline, like a job in the Jenkins pipeline. That's what I meant. I understand. But yeah, I don't understand this part. So basically it's just Jenkins pipeline compatibility in the plugin. Okay. Yeah. So yeah, maybe I missed this too. But yeah, for me this part just doesn't provide enough context. Okay. Integrate the plugin in JEP 2-9 if it's used and if Jenkins is used there. That's for sure. Write a GitHub actions workflow to trigger a pipeline to calculate the next release version without explicitly installing a Jenkins plugin or using the CD tool. This part is quite interesting because basically here you say that you would do the same but without Jenkins. Do I interpret it correctly? No, without Jenkins is again a question here but this is something myself and Gareth would discuss that if someone or so the conventional comments plugin GitHub, if I comment there or my PR is merged, then a GitHub action workflow would be triggered where this plugin will run and it can automatically detect the next semantic version. Yeah, because yeah, why I'm asking there are plugins which already provide support for semantic version and GitHub actions. So my interest was to understand what exactly you want to do. So because if it ever loves this existing plugin for GitHub actions, then probably there is no sense in that if it's just whatever integration between GitHub actions and Jenkins, then we need to understand what would be this integration because right now it's not clear. Okay, Uli, can you share the link to the doc where you mentioned whatever the meeting notes? Meeting notes is just a standard GSOC official stock. Okay, okay, I understand. So anything else you would like to ask? Do you still have time? Yeah, so like can you just a little bit like tell me about the Maven repository, like what are we expecting? Like whatever I have the idea is I know like the main initial idea or the inspiration was from the customer package or like it does that and some of the features we want. So you mean for the installation manager? What exactly? Am I so online? I want to show no longer online. Is anyone else online? I think we lost connection. Yeah, okay, let's wait a bit because I'm not sure what exactly we should be discussing right now. Okay, while we wait are there any other questions? So most of these projects are like basically improving the Jenkins model or something because what I see is like the architecture which Jenkins follows say like in my job profile we use Jenkins food to do deployment of various applications. So whatever projects is proposed here, it's just like something improving the Jenkins model or something? It depends. So there are multiple proposals. Some proposals are like integrations with external tools. So for example, integration with cloud events, integration with tip-on pipe clients, with well improvements to Jenkins Kubernetes separators, also parameters monitoring. So these are about integration with external tools. Then there are some projects which are related to adding new features to Jenkins plugins. So for example, these credentials are just improving how binding works or working on a custom Jenkins distribution in my service, which is a separate project, but it's also a lot to be done there. And yeah, that's it. So we do not exactly improve Jenkins model right now in proposals. So we had some proposals related to past here. But yeah, right now it's rather practical changes which would provide some features expected by users or some integrations. Okay, I got it. So yeah, in such a case, I think we can slowly close down the meeting. And if anyone has any questions, we can pull up or offline in the chat. Okay, so thanks all and I'll stop the recording. So if needed, please ask any questions in the GSEC chat. Okay, thank you so much. Thanks a lot.