 weekly meeting for the Jenkins Google summer of code program. At this time we have sent our application to Google and are awaiting for the timeline to come to the decision. And today we have on the call Arnab, Oleg, Nisarg, Oliver, Voutuan, and myself. So others may join later. Okay, so do we have meeting agenda items? Yeah, maybe you want to share your screen at this point? Yes. Okay, do you see the JSOC SIG meeting notes? Yep. Okay, so does anyone have meeting agenda items that they would like to add? Okay, so I've added my agenda item which is the documentation, documentation plugin. If Kristen makes it to the meeting we will discuss it. So we will also need to discuss other project ideas and especially since Voutuan is on the call and waiting for his feedback regarding the remote monitoring plugin before we actually publish the proposal. So yeah, if you could discuss it, it will be great. Okay, sounds good. Okay, so should we start with the Q&A? Yeah. Okay, so is there questions from the participants? So maybe you can ask questions as we go through the meeting. Yeah, it would be useful. Yesterday we had a session for a strategy plugin and I'm currently many interested students there. So we had a Q&A there. So maybe it explains why we didn't have so many people on the call today. Okay, okay. Alright, so action items in a cup. Where are we with regards to the action items? Okay, so Jeff is away, Lloyd is away. So we always record the JSAF meetings, which is what we're doing. Idea status review. Let me just scroll to see if we have action items. Yes, so for project ideas, we had an action item on Jeff to process the code cover API proposal from Shimeo. It seems somebody will have to take it over since Jeff has network issues. I will probably do the pull request on the evening. Okay, thank you. Yeah, I'm not seeing this here. Maybe it's not captured. Yeah, it's not captured in the meeting notes. Last week, we also had two action items on me. One is create internal Google Doc for mentors so that we can share information about students. It hasn't been completed yet. And pretty much share the same with scheduling internal mentor meetings. So let's try to do something starting from next week. I will send the video today. Oleg, can you please repeat the last point? Which one? What you just said, what hasn't been completed? You just said something hasn't been completed yet. Yeah, action items from the previous meeting. So we're going to do the mentor meeting for mentors etc. Something you need to create. Okay, cool. Oleg, what is the pull request that you're going to do for Jeff? Is it what's the proposal? CodeCover GPIE. If you open the coordination document, it should be in the bottom. I mean, we have a table with all project ideas in Google Doc. So if you open that, yeah. This one hasn't been published yet, even as a draft. I see. I have a question regarding these project proposals. I've noticed that, let me just go to the template. The template now says project idea rather than project proposals. Yeah, so I just decided to change it at some point because project idea is what we actually propose to students. We don't propose projects per se. That's why I edited that, but I don't think that it's important change. So yeah, it makes some sense, but there is no need to go and modify all published projects. Okay. Okay, sounds good. All right. Okay, other action items? Yeah, there is some action items on me from previous ones. Some updates have been assigned as BDFL database for GSO create, about GSO budgeting. A long story short, yeah, it's fine to do whatever budgeting we need right now. But in the long term, there is ongoing discussion about Jenkins project joining the Continuous Delivered Foundation. If it happens, we will need to revisit this JEP to adjust the new expense process. And yeah, I believe that there is no much sense to accept JEP right now just to create another JEP in a few months. So I think that I will keep it open. Is it JEP 13? No, it's JEP 8. JEP 8, yes. Okay. Yeah, because that's it on my side. Oh, yeah, that's what distribution for 2018. I'm still waiting for stickers from Sticker Mall. I will pink them to ask when it's delivered to date. Does it make sense to get started on the slide for 2019 already since it takes a lot of time? Yeah, I think so. So I always have something like 200 stickers, it should be enough. I mean, yeah, I have other community stickers as well. Yeah, it's generally, yeah, it's my fault that I didn't do it in August, September. Whoever visited Jenkins Vault, they already got stuff, but yeah, for others, we still need to do it. Okay. Okay. Thank you. Thank you. So other action items were an Artifactory, the Artifactory Proposal Publishing. And that was on me. And I think that's done. And the other ones were Jenkins Rest, and the Bitbucket Rest. They were both moved to publishing. So those were action items last week. So now we have five project IDs in the draft state. It's Artifactory, freestyle job to pipeline job converter. Pipeline sub-documentation generator. I believe this is on you and Christian. And also Jenkins remote in-community program, which we need to discuss with Wutong, but generally, it is still going to be changed as I proposed. And we also have a project ID for core coverage, which we haven't published. But if we do all of them, we are getting to 27 project IDs. That's impressive. Yeah. When I said that I want to have 30 project IDs in October, I didn't actually expect us to hit that. But it seems you may do that. Well, just have to set the bar high enough and people will try to jump over it. Okay. All right. I think the big discussion today, the big questions that were asked regarding, were regarding the advanced discard build step plug-in. So do we have, let me just check who we have on the call. Yes, we have Nisgar on the call. Hello, Tracy. So let me bring the let me bring the discussions that have been happening on the mailing list regarding the discard, the advanced discard. So we have a user, Torsten here, who is proposing or asking questions regarding discarding builds in the multi-branch pipeline job. And I've been trying to understand how multi-branch pipeline jobs work. If it helps, I can provide an explanation. So multi-branch pipeline interacts with source control management system. It pulls the repository and for branches for pull requests, it's able to create branches automatically and to get builds running automatically. And it has some retention strategies. For example, when the pull request is merged, it can close the branch for this pull request. And yeah, it also has all kinds of history management. So the biggest problem for multi-branch, and for example, we experience it in CI Jenkins IO many times, that it may consume a lot of space. Because if you have 100 open pull requests in your repository, then you have 100 jobs in action there. So proper management of history of artifacts and proper removal of these artifacts would be really interesting. So how does it work with regards to the build history? So do you get one Jenkins job per open branch? Yeah, if you want, I can just share that. Yes, please. Okay. Yeah, I have 13 minutes before my next meeting, but I'll do my best. Stop sharing. Okay. Okay. Okay, do you see the screen? Yes. Okay. So yeah, let's take real example. So Jenkins CI Jenkins. It's our Jenkins core. And we have multi-branch configured for this repository. So for example, if I click here, you may see that there is some automation happening. This automation, no wonder, is powered by Jenkins. So if we navigate to the instance, you may see that there is actually by the default, which is called the bloatian web interface, when it loads. Yeah, I'm not sure why it's, it's load to the, okay, it's bloatian. It downloads a lot of JavaScript stuff. So you may see that there is a number of steps executed, but you may see that actually this is for one, two, seven, all, which is a pull request number. If we just go to the code job here, you may see that, yeah, there is a kind of dashboard here. You may see that there are multiple branches. And here in the web interface, you may also see that there are branches and pull requests. So if you go to branch, you may see that there is a number of branches in Jenkins. And for each branch, we have some information. So for example, if we navigate to master, he is that, okay, so it seems it doesn't work in such way. We have always an option to show a classic Jenkins UI. So yeah, now it's probably less fancy, but it does the job. So if you open any branch here, you may see that there is a number of commits, or a certain number of builds. So for branch Java 10 support, the last build was this September 20, you may see that there are four builds. And for these four builds actually contain attached artifacts. And you may see that they consumed some disk space. So for example, Jenkins profile consumes 70 megabytes, it's about 100 in total for the build. And here we have 400 megabytes just for this branch, which has been actually last built in September. And most likely nobody needs that. And this is a problem for Seattle, because when we have so many branches, actually, it means that we consume a lot of disk space. So if you had advanced, whatever, discard builds plugin, which would be able to somehow operate with built to discuss on their multi branch level, it would be an interesting project. Because yep, we can immediately use it on the CI Jenkins IO. It's a constant issue for us. Okay, does it explain the use case, at least my understanding of this use case. So there is one build history per branch. Yeah, so each branch or each pull request, they have separate build history. For example, this pull request 1481. I have no idea what is this Jenkins Jenkins. Yeah, we can open that. So you may see that extension points can write characteristic environment variables. This pull request has been created by Oliver in 2014. It's still active. And you may see that for this pull request, we have we store more than 20 bills. So it's about two gigabytes just for this branch. And this is active. So yeah, it's a separate build history. And for each branch, you could use current discard logic to manage this card so on a single branch. But again, it's not clear why this bill, for example, wasn't cleaned up here. And the advanced discard bills plugin could be actually managing that thing in a better way. Okay, I think I understand the use case better. Now, if the pull request gets, if it's not merged, if it gets a closed without merging, what happens here? Yeah, here we so I would need to show configuration. Unfortunately, I have no access to this instance. But multi branch. So here multi branches configured on this level. So it's a GitHub organization. And the author is not a GitHub organization. It's multi branch project in this case. And you can set up different retention policies for branches. So for example, when you merge the branch, you can configure Jenkins to automatically clean up build history, or you can configure it to delete build history after a particular time, if I recall correctly. But there is not that much flexibility about that. So if the branches closed or denied without merging, the job will stay in this on this page, it depends on how multi branches configured. So multi branch project as API, it supports any behavior. So you can delete this history, you can retain this history depending on what you want. But yeah, it really depends on how it's implemented. Some some of these pull requests are like integrated, but they may still have a branch. So yeah, I can just try guessing. But yeah, without guessing, some of them may have been already integrated. Oh, so the branch could urge and the build history will remain for some time, and then it will be integrated. Then it will be removed because the Jenkins doesn't start ready to forever. Okay. Now so this proposal from Torsten would be an interesting addition to the project. I definitely agree with it. And actually, we have a pipeline authoring special interest group meeting in 30 minutes, I guess. So you could probably ask Andrew to have a discussion there because there will be more pipeline experts on the call. And they probably could provide more ideas in terms of what could be actually done for in addition to the current implementation. Because I know the feature I use the feature, but I'm not sure what is the current plan for extending it. Okay, yeah, I'm, I think I will attend. I will attend the the pipeline authoring SIG. I have to think about this problem a little bit more. Nisarg, do you have some ideas, some questions? Yeah, so actually, I have not been working. Actually, I have not yet explored the multi branch part. But I think as this was presented, I got some idea. And I think that if we want to implement this, then it would be a better idea as if builds are remaining present in multi branch. And if the merge request, if the PR is getting merged, at that time, we should discard that build so that this space gets free. Well, generally Jenkins approach that if you can see the multiple behaviors, you add an extension point. This is what multi branch already supports as far as I can tell. So you can define more different policies, and you can implement policies as extension for Yeah, sure. So like, we can add some policies or some filters like like if this pipeline or this build has some criteria or some property, then we can just discard that build or it just discard its artifacts. Yeah. So from advanced build discard the plug in standpoint, it would be just extension point implementation for multi branch, which integrate somehow with advanced build discard the plugin logic itself. So you have your own logic and due to why extension point implementation, you can integrate this logic with multi branch pipeline. Yes. So like, we just have to define our, you know, flow or our own logic that how we want to discard the builds and at what conditions we want to discard. So it's so like, just defining it as extension point will be but like a preparing a flow or preparing, you know, logic that how we want to discard that build and generally how we want to deal with it would be much more interesting. Martin, you're muted. Sorry, I can't. There is there is a sorry, there is another idea from Thorsten, which is he wants the ability to mark the build from inside his Jenkins file pipeline. He suggested that he could mark the build with some flag that the that they extended that the that the discard plug in would be able to read and based on the value of this flag, decide to discard the build or not. But I was not clear. It's not clear to me. Like I know the run selector can choose a build based on different parameters in the build. But I don't know if it can query a user specific flag that the user has set inside inside their Jenkins file. Any suggestion on that? Yes. So I have one point on that. So like, you know, if someone have, you know, multiple pipelines and multiples in an or like, or like that, and if they have pipelines, like one pipeline is off QA testing, right? Second pipeline is off pre production pipeline, then third one is off testing, then fourth one is off production, right? So like, and there are some pipeline, if a particular code is being tested in a particular pipeline, then that name is fixed for that. Like for some core for some testing, they will use QA testing for some pre production test, they will use the tag pre production. So we can just give a facility to give a tag and based on that tag, we can just decide that which build we should keep and which should not like if some if some pipelines are really necessary are really important till the production stage, then we should keep that builds and it's artifacts. But the one which are not necessary, I think that can be removed and it will be much more optimized. Okay, I just I agree with you, it would be much more optimized. I'm not familiar enough with the code base to, to, to evaluate to evaluate if, if, if a proposal doing that will work or not. Yes, I don't know how, how easy or hard it is to set some flag in the build and have the run selector find that flag or that piece of data. I, I know the run selector can read the the build parameters, for example, that's clear to me. But yeah, if it's something else, I don't know how it can read it. Yeah, okay. So actually, I was just looking at the code base of you know, run selector, just yesterday or two days before. And you know, like, I was just finding a way that how this idea can be implemented with code and this run base selector. Yeah, so you are right. Like, to just finding a way would be would need much more work. And we don't know the difficulty, like, sometimes it, like, it would be easier to integrate it, it can be also like, we just need some more time to, you know, just think on it and take a decision to add this in a project proposal. And actually, one more point I would like to add, like, just we, like, I and Torstein had a conversation, like, he just proposed that we can store, you know, like, just a minute, I'm just looking at the chat. Just a minute. I'm sorry. Yeah, so here it is. So he just told that we can also, we can also, you know, store not exactly the world, but yeah, we can also create a, you know, data structure in which there will be a key and its value, right? So like, basically, I just thought it and I thought that a type of hashing would be better for this. So a key and a value. Now, what would be a key, like, which build has been deleted, like, which has been discarded, and its value would be by which filter it gets discarded. Right? So now by keeping this track, how we can benefit the users, like, like suppose we are storing the bills in this data structure, like last 10,000, last 10,000 discarded bills we are storing this data structure, right? And now if anyhow, someone want to get the log or the bill or the artifacts of the previously deleted bills accidentally, then we can give access to them for a few hours or for a few days. Or we can also, you know, use this set for some other, for some other use cases also, like, I don't have any particular or a specific use case right now. But I'm just thinking on it currently. Okay. Um, I think this, um, yeah, I think we, there needs to be more thinking with this, with this process, with this plugin. Yes, yeah. And also, when it comes to the implementation, we'll have to discover what is possible and what is not possible. And but these are all good ideas. Sorry, these are all good ideas. Yeah, thank you. And, and actually one more solution I would like to add this that like, suppose if we are keeping this data structure thing in, you know, like if we are using hashing technique or something like that. So if accidentally someone, uh, want to get a particular log or a particular build, which needs in few hours or, you know, just in a sudden while, like, if he has given some wrong, wrong tag or some wrong filter to that build and that build got deleted due to our, you know, logic, then, then also we can, you know, give access to that user at, at some extent to get his logs back or get his, uh, build status, uh, for some time. Like we, yes, we cannot give him all complete details, but, uh, we can give him as much as possible. Oh, I think I understand what you are saying. Let me repeat it to make sure you are saying, um, you're proposing that the build this starter would, uh, well, it would discard the build, but it would kind of put it aside. Yes. Yes. And, um, it would be in this, uh, I don't know, uh, recycling bin. And if the user needs to access it, uh, we could, it could be brought out of the recycling bin and back in the history. But after, after some time, the, this recycling bin would be just, uh, flushed and clear and deleted for good. Oh, yeah. Okay. Yeah. I think it's good. It's a good idea. So that's what I am proposing right now, uh, to give you some more features to this plugin. Yeah. So that can be part of the student proposal. Yeah. Thank you. And, uh, I have one more doubt in the proposal. Uh, the second point, like, uh, currently it is not able to delete the external workspaces created by external workspace manager, right? So, uh, this is a current situation of, uh, build this kind of plugin. Correct. Yeah. So actually I have a doubt like, uh, uh, so it's just a general doubt. Like, uh, if we want to delete the external workspaces which are created by the external workspace manager. So first of all, we need to delete the bills and, you know, all the details from the third agent which has been used and after that we have to delete our build or, uh, first we have to delete the build which have been displayed into Jenkins dashboard and up and the, uh, bills or the, you know, information which that third party tool has made, uh, is not to be deleted. So I just, uh, want to clear out from the example. So I'm just having a confusion that, uh, that discard will be done from both Jenkins and the third party tool or only from Jenkins. Okay. So you're asking if the external workspace should be discarded from Jenkins or from the plugin? Yeah. Is that your question? Yes. What the discards are, are being, uh, um, it's the build discard or plugin that, that does the, oh, wait a minute. Um, no, I think it's the build discard plugin that does the discard. Wait, wait, uh, you can have extension points on build discard. Yes, we can have an extension point. Yes. I think it would be the extension point that does the discard. Um, I think there's links in the build discard plugin to some existing extensions of build discard. And in those extensions, um, we can look, you could look in the source code and see, and see how those, um, existing plugins, existing, uh, discard extensions work. Uh, sorry. Uh, in which plugin should I look? It's a build discard, right? Okay. Let me, let me see if you can still, uh, if I can still share my screen, uh, build discard again. Uh, so actually I got this query, you know, from a person who is using Jenkins frequently. So actually he just told me that, uh, sometimes what happens that, uh, they use this, uh, they use this plugin, uh, of external workspace manager, right? And, uh, the builds which were, uh, and, uh, you know, uh, the builds were only getting discarded from Jenkins only that external, uh, you know, third party agent or the tool was keeping all that builds. So they should also be deleted by making some API calls or like that. You mean the external workspace manager should discard the builds? Yes. Yes. From the extra, yes, from the external, uh, agent or the tool which, uh, it has been linked or like that. I, I don't, um, I don't think I can provide like a final answer, a definitive answer to that question because I'm not, uh, I'm not a Jenkins developer actually. Okay. So I don't know the source code. I don't know where these things happen exactly. Um, we would need, um, we would need to talk to probably, um, Alex Shomai, who is the author of the, um, external workspace manager and probably Oleg in like, we should, we would have the, we would need a discussion with them. With them. Yeah. Yeah. Right. Right. Parting the details. Yes. Yes. Yeah. So I can just mark it as. Yeah. Just a minute. But it's good. It's a good open. It's a good question. Uh, yeah. Thank you. So maybe you want to post it in, in Gitter. Um, yeah, sure. I'll just, you know, frame that question, uh, in a particular manner and I'll just post that on Gitter. Okay. Yeah. Uh, and I was just looking through the project proposal. Um, so in, you know, that the, the three points which we have, uh, given that, uh, in existing plugin and scenarios discussion, I think, uh, the second one is the one which we currently, uh, just discussed the first word. The first is pretty clear that, uh, what, uh, the feature, uh, is, you know, what, uh, which type of feature, uh, needs to be implemented. Could you share your screen? I'm not sure which section of the proposal you're talking about. Uh, I don't know from where, uh, I can share my screen or that. Oh, um. Yeah, just a minute, just a minute. Yeah. Just a minute. I just ordered. Screen share. Um, Okay. So let me stop my sharing. Yeah. Okay. We see your screen, I think. Oh, yeah. So now we can see my screen, right? No. Oh, okay. Yeah. Just a minute. Um, share. Yes. Yeah. Okay. So I am, I, uh, so the first point is pretty clear that, uh, what is need to be implemented. So like, uh, it just can't keep, uh, the last 10 builds, uh, due to some age, uh, or, uh, some filter and all that, right? So right now there's, uh, two features and they work only in one way. So yeah. Okay. And this is, this is highlighting, uh, a limitation of the current plugin. Yeah. Okay. So, uh, the current situation is that we can only keep builds for 14 days and up to a certain limit of 50 builds, right? Uh, actually no. The current situation is as soon as one, uh, okay. So the key is the text in italics before, uh, right below. It says if either limit is exceeded. Yeah. Any builds beyond that limit will be discarded. So, okay. So if, let's say you always want to keep the last 10, regardless of their age. Yeah. Yeah. Yeah. So I got, yeah. So, yeah. Yeah. So actually, uh, I was just looking at the core of log rotation and, uh, yeah. So, uh, I think these which I can implemented, uh, the way it is written here, right? So it's not an issue, right? Uh, the second point was, uh, just we discussed that what exact feature should be implemented or it should be included in this project proposal or not. So we need to discuss much more for this, right? Yeah. Uh, uh, for the third point, which users are not able to keep builds that are part of brands that lead to production. So that's where, you know, uh, we need to, uh, so, uh, like one thing I would like to say that if we do not, uh, you know, give some facility of tagging or naming or description, then, uh, there should be a way to find out that which stage is of which situation likes, uh, see, uh, here it's written that if you have built pipelines which contain stage name like deploy to test and deploy to production, then we can just, uh, know that, uh, these stages of this purpose and these stages of this purpose. But, uh, if we don't have any clue or we don't have any, uh, you know, if we don't have any description, then we cannot, uh, get or I think it would be not much more appreciated to discuss, uh, that builds because we are not pretty much sure that, uh, that stage is of, uh, that stage is for which purpose. Yes. It's very user specific in this case. Yes. Yes. So, actually, this third point needs some more elaboration that exactly how we are going to approach and what facility, uh, and are we giving some facility to, uh, to them to choose, uh, what they want to discard like, uh, giving some checkboxes that this, this, this, uh, stages can be discarded after some time or like that. Or I think like, uh, we should give you some, uh, some type of, uh, that feature or something like that. We need to define a specific path that how we will, uh, lead to this problem and solve this. Yes. There, um, you're right. I don't know why it is a, it is a request for the discard to have a way to do this, but how it should be done, I don't know. And I would say there's, uh, there's even a fourth item which is ignoring, if we ignore item three, there's a fourth one that Oleg presented earlier, which is in a normal operation, um, the builds will stay in the history for a very long time and it's not clear when they are deleted or whether they are deleted or not. Regardless of item three here. So, uh, the, the discard proposal should, should address, um, should address what Oleg presented earlier. Yes. So, actually, I would like to, uh, add a point into this. So, yeah, uh, actually, he's right, like, when, uh, I, you know, just got, uh, first time to Jenkins and when I just started using it in my first, you know, in my first year summer internship, at that time, uh, when I, uh, started to build the pipelines and just, uh, started building it, the, uh, the, uh, builds what, uh, like, uh, we were not pretty much clear that when that build will get discarded or for how much time it will be there, uh, in history or like that. So, like, uh, we can add a feature in this like that, like, uh, you know, a special tag or a special word for like that. Like, suppose if someone, uh, attaches, uh, some, uh, like, like, suppose we just introduce one tag like special, right? And if someone, uh, uh, just addresses or attaches that tag to that pipeline or to that build, then that build won't be discarded until that tag is removed from that pipeline or from that build. Otherwise, the other builds, uh, for that, we can define a particular day or a particular filter by which we can just discard them. If user, uh, does not choose their filters or their choice. Yeah, there's many, many options here. Um, we also have to think at scale, what if there is 100,000 builds in the, on the Jenkins instance, uh, we cannot expect the user to go click a button in 100,000. Yeah, yeah, yeah. So, yeah, so we don't, so I mean, for an exceptional circumstance, it could be done, but for 100,000 builds, it's not practical. Yeah, it's not right. So can you just, uh, add, uh, that statement into this proposal so that, uh, we can, you know, get a question like, or some, like, I think I'll just, uh, think about it more and if I get a specific solution, like, uh, buy something or buy some external user, like, by anything we can, uh, may, you know, solve this problem. Yeah, I can add, I can add, um, another item to this list. Yeah, so, uh, I think they are stating the, stating the problem. Yeah, sure. So I think the existing plugin, the scenario discussion is completed and this proposed new plugin discussion was, I think, uh, you know, like, like, it's almost clear to me that, uh, for, on what basis and on what conditions and on what filters we are going to discard or we are going to, uh, indicate builds to discard. So I think it was pretty clear and, uh, straightforward. Right. Uh, and, uh, the possible implement, like, the, you know, examples were, I think, also clear. So, uh, now I think I have one doubt in quick start, like, not in quick start, but, uh, I have one doubt, like, uh, in this run selector plugin, there are only, uh, two to three, I think, Java files which are related to this advanced discard build plugin. If I am not wrong, I don't know the, I don't, like, actually I was just, uh, looking at the core base and I just found that, uh, the status run selector, then this permalink run selector and, uh, some of the other run selectors are only useful. So I think only, uh, so, like, I just, uh, want, uh, few suggestions that which filters or which Java files specifically should I focus to, uh, you know, get useful or, uh, like, you know, somewhat, like, like, like, I mean, get useful to the core base of this. Yeah, um, so I think it's, uh, important to, I think you can pick one of them. It doesn't matter which one and, uh, you can study how it is implemented. And because when you, we probably need to add new, um, implementations in the run selector, uh, to cover the other cases that, that we are discovering with the advanced discard, advanced discard build. So maybe the, the, the, the answer needs to be created here. I would like, because there's only a few minutes left and I see that Arnab is still on the call. So I wanted to know if, um, I wanted to give him the opportunity to, to talk if he has something to say. Well, not much to add from my side. I think, uh, I think from what I'm understanding, Nisarg is taking, uh, quite good initiative. I think in the project, he's trying to understand the project. So, uh, yeah, so nothing to add. Actually, uh, I, I myself, I learned quite a few new things about this project between your discussion and Nisarg's discussion. And Nisarg, I think if you have any doubts, you can, like, like Martin said, if there are any doubts related to the code base, you can maybe frame the questions on GitHub. Then Oleg or the others, uh, other senior contributors who have directly worked on the code base can, I think, guide you there directly. So yeah, nothing much to add from my side, Martin. Okay. Okay. So we're, um, we're almost out of time. Is there, um, is there anything else? Uh, yeah. So only just, uh, last question, like you like, uh, see actually what, uh, I, uh, only one problem which I am facing right now, uh, in studying, like, uh, like, uh, here it's mentioned that contribute to existing related plugins run selector, right? So in quick start, uh, the statement is this. So, uh, when, uh, like, not me, like if any of the student opens, uh, that code base and all that. So it's a huge structure to get understand and all that. So if in quick start, if, uh, more description can be added or more, uh, newbie friendly, uh, issues are added, which are useful to this plugin are much more appreciated. So, uh, uh, so, uh, like, actually, I'll, uh, just to say that, uh, I just, uh, started contributing to Jenkins in, you know, uh, the end of, uh, January month. And I just, uh, went through some of the issues with newbie friendly tag and in the core code base and I'll, uh, and I just started working with two of them. So, uh, like if a particular issue or a particular, uh, Java file, which are important in run selector or in, uh, like any of the part in Jenkins, and if, uh, they are mentioned, uh, in a very particular way or, you know, a specific Java file or a specific issue, uh, I think that would be much more better for a student to, uh, you know, uh, understand the whole structure and, uh, yeah, that's all. Okay. Um, I don't, I don't have this, the issues that are listed, there are the ones that we have and sometimes there's no newbie friendly issues because people do not, users do not take the time to create issues for their problems. They just go on the mailing list and they talk about the problem. So oftentimes there's no issues with regards to the build discard plugin. Um, if you allow me to share my screen one last time, um, here is the advanced. Okay. The only, you know, the most simple thing, um, is with regards to item one, um, okay. Yeah, sure. So I'll just go through this item one and I'll just, uh, serve to the, you know, code like, uh, where the changes can be made or, uh, where, uh, new code can be applied in which part to make this implemented. Yes. That would be a good way to get familiar with the code. And also I want to point out at the bottom here, um, just a minute. There is build this carder. Yeah, there is. There was a plugin. I thought I listed it. I think you were talking about the old discard plugin. Yes. Uh, yeah, uh, actually I saw that in your 2018 proposal, old proposal, like I was just, uh, this one, this one enhanced old build discarders. Yeah. This one is a very simple example of using the extension point. Um, there you go. Again, site go to get hub. Yeah. I, yes, I have studied this, uh, code of this enhanced old build discarded, like it, yeah, like it was pretty much clear to me. Okay. So if we ignore the multi branch plugin, yeah, I think that all the features that talk about, um, using the run selector and using the different filters, uh, could be, could be implemented by, um, let's say, um, making this plugin better, this one, the enhanced old plugin discarder. Okay. So you are just saying that, uh, uh, the student, uh, who works on this plugin needs to make this code much more better, right? I think that using, um, I think that this plugin enhanced old build discarder. Um, so it proposes, um, it implements a, uh, an extension point, which is a strategy for the build discarder. And so this plugin could implement multiple build strategies. Yeah. Discard strategies. Yeah. So actually, uh, right now, uh, we have, uh, a build discard plugin, right? At a very, uh, few feature limits and, uh, in, uh, what, uh, like, I just, it's in the core. It's, it's not the plugin. It's in the core. Okay. Yeah. So, uh, yeah. So actually I was just confusing that, uh, so the changes and all these updates are needed to make a new plugin or to make an existing plugin better or in the Jenkins core. Yeah. Yes. So it should be definitely in the plugin. Um, yeah. Now the student, the student can propose to create either a new plugin or to use to, to further enhance the old build discarder plugin. So further enhance this one. Yeah. So it's part of the student proposal. Okay. Yeah. Okay. Yeah. So I just got that. So, uh, a student can make a new plugin or, uh, he or she could, you know, just add all these features into this existing enhanced old build discarder plugin. Yes. So the student needs to put that in their proposal. Yeah. Yeah. Yeah. Maybe, maybe discuss the two ideas, a couple paragraph or two. And then the student says, okay, here's what I propose for the implementation. One or the other. Yeah. Okay. We're not, uh, in this, um, open source program, the mentors do not dictate their implementation. The student has to come up with their own proposal. Yeah. And then it gets discussed and usually we find, uh, the, a good solution during those discussions. Um, Okay. Yeah. If I know for sure that, uh, a solution is better, I will discuss it. But, uh, at this time, um, I don't know. Okay. And, uh, last question, like, is there any suggestions or, uh, any, uh, you know, tips for, uh, for looking on code base currently, like, or any particular work should I do to get into this proposal and to write a better proposal? So there's no new B friendly issues that are listed if that's what you're asking. Yeah. So, so like just any, you know, not any issue or not any code, like any suggestion for which should I look or, should I change into my strategy, uh, for working with this project or like that. Other than what we already discussed, I don't have other suggestions. Okay. Yeah. Thank you. Okay. So, um, it's, uh, it's, um, five minutes past the end of the meeting. So I will, uh, I propose that we adjourn the meeting. We come to a close. I have another meeting to attend. So I want to thank you for attending this meeting and for being so active. Um, uh, with the JSOC project. Uh, yeah. Thank you. Thank you very much. Okay. So, all right, uh, we'll stop the broadcast now. Cool. Yes. Bye.