 Today is March 20th, we have a regular GSOC special interest group meeting, so the purpose of this meeting is to firstly sync up on the GSOC project including complications, action items on the mentor's side, and also have discussions with students. Right now from what I see we have worked on on the call, the rest of the participants are students. So I think we will just start from 20th session, and if you get a moment or slightly we will just proceed with common status. Okay, I will just start the screen sharing then. Do you see my screen? Yes. Thank you. Yeah, so let's take a look what we have in GSOC timeline. The applications are two GSOC open soon, so you may see that March 20th it's less than one week, it's official period when you can start submitting the applications, but I keep in mind that it's just the first time you can do that, but we really suggest you start drafting the applications as soon as possible so that you have more time to discuss it with your mentor's side to get your applications reviewed. We have already received around 10 drafts from students, and we are waiting for more. So yeah, if you're interested please do it as soon as possible, that's the main deadline. What else do we have from the schedule? So April 9th it's given nine weeks, so it is in three weeks. So it will be deadline for applications. So everybody should submit the application by this time. If you don't submit, there is no way you apply to the program later, so this is a hard deadline. If you miss that, then you miss the application, and this is another reason why you should start submitting something earlier so that you have more time in order to discuss and polish your proposal, but if anything goes wrong, you don't miss the application. Usually, yeah, I'm not sure what was statistics from the previous year, but many applications have been submitted over the last couple of hours, and the written instruction is always doing that because of the JSOC site is just a site, so it may be easily overloaded, and it's easier in order to do it again. So yeah, this is the main two incoming dates, and we will start with them. If you're interested, you can find all the project ideas here. So you may see that almost all project ideas are in the published state. We have only one project idea in the draft state, but as we discussed today in Gitter Chat, we will be also working with it to publish because all comments are addressed, and you can apply to any project idea, and if you're interested, you can also create your own project ideas. So yeah, this is summary of the current application status. So yeah, we must work with students. As we discussed before, we have two regular office hours slots. One is on Tuesday, it's ATM UTC, another one is to be at four PM UTC, so it's in two hours, but since we don't have many mentors on this call, we can just press it with Koine. Does it sound good to everybody? Okay, so we had a plan to have a discussion about the remotely projects. Maybe we could park it a bit and start from other questions. Anya? Yeah, I have a question. So I found, I saw one of the projects on that website you had showed, and I then later saw that I should send an email to the Google group saying I'm interested in it, which I haven't done yet, but I saw that there were some potential mentors, but there wasn't anyone listed officially, so is that something like those don't get listed until your application gets accepted, or is it just that like that project isn't as well, kind of like the initial steps aren't as fleshed out? No, so I believe it's about Institution Manager, right? Sorry, what was that? It was about this project, right? Yeah, yeah. Okay, so what does the current status mean? You have potential mentors, you already have the right mentors, there may be more mentors joining later, but until the project's announced, we will have only potential mentors here. Why? Because it really depends on other applications, it depends on the mentor plans, and you may see here that there is a period between the application deadline and application announcements, sort of project announcements. So during this timeframe, we will be selecting the mentor teams for each project. If we need more mentors, we will be looking for them. So please expect that in every project, we will have at least two mentors. And here, we just have a potential mentors as contacts. So it's me, but he's probably he cannot join today, but yeah, feel free to reach out to these potential mentors. There is a Gitter Chat, there is a mailing list, so you can use these contacts in order to reach out. You can send a direct email to mentors, but we highly recommend to use these channels because you can get more visibility of your application, mostly colors and probably more mentors at some point. Okay, thank you. And then another question that I had is, so I noticed that the potential mentors who are located in Europe, and I'm located in the Americas, have you in like times past, have you found that is that a problem like with students being able to get like the help that they need with the time difference? Or is that something that is totally fine? I just wasn't sure if I should take that into consideration when trying to pick my project. So yeah, it's a part of open source work. The most of open source projects are distributed, and you have to be ready to different time zones. Regarding this particular mentors, I believe it's fine, but yeah, when you apply, it's nice to have some discussions with mentors so that you make sure that everything is fine. Again, the recommendation is to just ask about it in the discussion, and if mentors are fine, they just proceed. Yes, some mentors make up difficulties. So yeah, you won't be able to effectively run the project if we have a student, for example, in Asia, one mentor in Europe, one mentor in America, so then it might be a problem. But it's our objective as an organization to find mentors who will be at least who will have some overlap in your time zone, because we need to schedule regular meetings, we need to schedule sync helps, and for that, yeah, our objective will be to find good times on another level. So in your case, it's not a problem for sure. Okay, thank you. Okay, any other questions? Yeah, so like, I have a few questions. I was thinking that I should wait for Martin so that, you know, I can ask to the proposal can be solved. Yeah, so like, I am just waiting for him to connect, like, whenever he joins, I'll just start my query. Okay, so maybe we put on some other questions for now. Okay, anything else? I have one more question. So I saw that there's, I guess, a couple different means of communication. So there's like, Gitter, you have this Google group email, and then also like IRC. So I was just kind of wondering, like, when each of those is used, or if there's like some community norms about when to use one versus the other, or, yeah, I don't know if you have any, like, feedback on that. Yeah, we do have IRC, but in these projects, we target Gitter. So I believe there is no projects using IRC right now. IRC is still used as official Jenkins communication channel, for example, for governance meetings and for other synapses. But yeah, many special groups, subprojects, they actually moved to Gitter. You may see that even here Gitter is now in the top, but yeah. Most probably as a part of your JSOD project, you will not need IRC. But if you want, you are welcome to participate in these channels. And yeah, speaking of projects, in each project, we have some, sorry, there is an error. Yeah, we have some communication channels listed here. So for example, here it's freestyle to pipeline job converter. You may see that the channels actually link to pipeline authoring, especially in this group, and there are two channels. One is mailing please, one is Gitter. What to choose? It really depends on your preferences. So we recommend to have longer discussions in mailing please and runtime discussions in Gitter. So if you need to sync up with your mentors, and you know that everybody is online because of the time zone, it's better to use Gitter. If you want to ask for feedback, and if you want to have a longer discussion, for example, about technical design, about some decision making, then it's better to use mailing please. But yeah, generally it depends on your choice. What we recommend is to use public channels as much as possible. There are some cases where you may need to use a private channel. For example, to discuss your ability with mentors, if you have whatever emergency, and if you want to notify them, or if you want to escalate the issues toward that means, then we use private channels. But for the most of the communications, including project proposal reviews, we recommend using public channels. So please use one of these channels, but each channel to take, it really depends on your preference. Okay, thank you. Okay. Yeah, Oleh, I want to ask this question. So actually, I feel that, I mean, this year we are moving towards more Gitter than mailing list, because I feel it's sometimes quite difficult to keep check everything on Gitter. Can we direct students to do, I mean, for my project discussion, I feel that if we use mailing list, it will be, I mean, better and easier to keep check up. Do you have any opinion about this? Yeah, fair point. Yeah, we have experience, actually, we do experience high traffic in the GenkiCIA JSOB 6 channel. If you participate here, you may see that there is a lot of messages and it's a hard part of the discussions. Unfortunately, it's not Slack, so there is no threads or whatever. And here, as Hutan said, it makes sense to really use the mailing list for other channels, well, as you wish. So even there is no high traffic, maybe Gitter is okay. But yeah, commonly communities recommend using mailing lists for long term communications. So if you expect communication to proceed for several days, like review, design discussion, mainly it's highly recommended. But if you just want to pick somebody for pull request review or something like that, Gitter is fine. Yeah, so I think we should direct the students to use mailing lists for the, I mean, for the next phase of project proposal and kind of things. Because I feel the norm now is people just go to a Gitter and ask. I'm not sure. I actually don't see much discussion in the mailing list from what I understand. Yeah, we do have some discussions in the mailing list. But yeah, again, we have multiple mailing lists now. So yeah, I think it's a fair point. So probably we need to update guidance to make it explicit. Or maybe you could propose a pull request in our guidelines. Would you be able to do that? Oh, OK, OK. I just put a note in so I will submit my pull request. Yeah, thanks a lot. Yeah, no problem. Thanks a lot for doing that. If anybody else sees any issues in our student guidelines, so if you want to propose changes, for example, reference additional information, feel free to propose pull request. So the entire Jenkins website is managed by configuration as code. And you can just submit a pull request to whatever page. Moreover, there is improve this page button. So if you just want to fix a typo or write small text, you can just use this button. So it just opens in GitHub. You can edit something and then propose a pull request. OK. Are there any other questions? Yeah, so like now, can I ask my questions regarding build discuss? OK. Yeah, OK. So I'd like to share my screen for showing the proposals. Yeah, please do that. But again, as we discussed before, it's better to have discussion with mentors. So if it's a top level thing, feel free to ask. If it's something about the specific details of your project, I highly recommend to use another channel for that. Yes, like I have a few questions regarding to my particular project on this. Like we can have a discussion regarding the general question. And after that, if time permits, I can ask my doubts. OK, let's finish with the general questions. And OK, let's just do general questions first. I have another one. So say like our project proposal doesn't get accepted to Google Summer of Code, but we want to keep working on it. So like what would the support look like for that? So like we wouldn't have assigned mentors, but people in the community would still be willing to help with that. Or would like the Google Summer of Code projects be prioritized? Jen can say, use it be community. We have several hundreds active contributors. But we have maybe 1,500 components. So the level of support really depends on the project you work on and on availability of people. Obviously, JSOC mentors will be like the PDBs with JSOC, but it doesn't mean that you cannot contribute. Because we have a special team which helps with code reviews. It's Jenkins CI Code Reviewers. So if you submit a public request, you can ask the base team to help. The same we have for many people who are interested in providing support to newcomer contributors. And again, you can ask for help. So if you're interested to contribute to Jenkins with JSOC, you are more than welcome to do that. In particular areas, it may be easy. In particular areas, it may be quite difficult. So for example, if you propose a code request to an abundant plugin, which doesn't have M&KR, then it might be difficult to get feedback and to get your change integrated. If you take an active component, for example, Jenkins Code, the most popular plugins are active, then everything should be fine, even outside JSOC. Moreover, you may have seen that now there are sub-projects and also special interest groups. So if you take a project within the interest of a special interest group, for example, I'm a leader of a platform group which focuses on packaging, on Docker, on Java support, et cetera. If you have a project in this area, you are welcome to join our regular meetings. And here you can find a lot of stakeholders there. There are other sub-projects and special interest group which you do the same. So if you work in this area, you will be able to have experience with regular stakeholders participating in the discussion. And we are happy to help you. But yeah, it really depends on your interest. So if you can clarify what would be your interest and for contribution in such a space, maybe I can provide more detail and advice. OK, thank you. OK. So just in case you don't get accepted in asking in the chat, it will be probably the best starting point. Other questions? I see Martin online. We'll start now and we'll turn. Oh, hi, Oleg. Sorry for joining late. Yeah, no worries. So I think I'll just move the mentor side of the discussion to the mailing list because I really want to facilitate some discussions and the advertisement for JSOC. We got a lot of pull-ups, but it still makes sense to outreach the students the way we can. OK, so I think we can just proceed with Kone. Just second, I'll check what is my agenda because we have a mass due to the recent time don't change in America. I mean, a bigger mass than usual. OK, so yeah, I have a meeting starting in five minutes, but maybe Martin or you could take over the discussion. Yeah, I can do that, Oleg. I'm sorry, Oleg, can you repeat again? It wasn't very clear. Are you talking about the next student officer? I'm talking about this meeting. OK, yeah, yeah, yeah, short, short. Yes, I'm there now. Yeah, we can continue for another 30 minutes. So probably I'll drop off at some point, but if Martin is ready to handle the discussion, it would be perfect. Short, short. Yeah, I can do that. Thank you. And for now, we can just proceed with Kone. So does anybody have any questions except projects? Yeah, since we have remote people on the call, I want to ask what do we do about the remote and discussion? Do we want to have it as a part of this session, or do we want to have a separate meeting for that? Yeah, so if the question is short, I think we can discuss on this call. One of your team need to wait for the student. Are you on the call? Yeah, I just want to ask about the remote specifically because it's time zone issue. So the student is, I'm not sure if I pronounce it correctly. His name is the last one, Lom. OK, so can I discuss about the project for both for remote and over Kafka ideas? So they have some points here, but most of them are pretty brief and I'm pretty confused about how to integrate a remote and over Kafka with Kubernetes. More specifically, implement connector logic using credentials from Kubernetes. Can you explain in more detail? You mean credentials management, right? Here, implement connector logic using credentials from Kubernetes. All right, so in Kubernetes, there is an existing engine for managing secrets. And what you would be interested in is if you provision Jenkins cluster from using Kubernetes. For example, in a simple Kubernetes code, you should be able to somehow automate credentials management. One of the ways is to just pass secrets using between the instances. Another one is configure Apache Kafka instance properly. So the idea that if you manage this infrastructure from Jenkins, it would be nice if you could manage credentials as well so that everything is automated. OK, thank you. And how about automated provisioning of Kafka cluster? Doesn't mean like Jenkins will start Kafka cluster automatically or something. Yeah, right. So how could it be done? Yeah, if you use Kubernetes, again, you can provision multiple containers. It would be interesting to have, for example, Helm charts or whatever, which would allow to provision Jenkins is Kubernetes cluster, this automatic provisioning of agents is Apache Kafka plugin. So just to have a way which automatically provisions the entire instance and which would be configured out of the box. It's one of the ways to do that. Another way is to be able to provision Apache Kafka from Jenkins master. So for example, you start master and Kubernetes and then you can use Qtctl or whatever in order to provision Apache Kafka instances from the plugin. Both ways could be used and it depends on your proposal. OK, thank you very much for that. The last one is create a reference Kubernetes definition and Helm charts for the Kafka system. This line create a reference Kubernetes definition and Helm chart. Can you explain this in more detail? Are you familiar with Helm? I'm not sure. I think Helm is like a configuration to start a Kubernetes cluster or something like that. Right? So Helm is a kind of package manager for Kubernetes. What we could do that, we could create a chart that would define Jenkins with agents, with Apache Kafka. So having an option to provision it as a system with all the integrated components. Oh, I see, I see. Yeah, it would require some definition in Helm. Maybe it will require some coding in Ruby for example, configuring of components like you need to pre-configure Apache Kafka somehow, you need to pre-configure Jenkins, you need to pre-configure agent provisioning and it can be a part of the project that you're interested in. Oh, I see, I see. Yeah, thank you. I think that's all of my question. Thank you. I have a question on the Kubernetes one. So is this is not related to Jenkins, is it already? Yeah. So we are talking about Jenkins here but if you want to propose the same for Jenkins sex, it might be also possible. But yeah, Jenkins sex is out of the scope or in my mind. Okay, okay. If students are interested to propose this project ID or any other project ID for Jenkins sex specifically with Jenkins sex flavor, you're more than welcome to do that and you will do our best to help find mentors from Jenkins sex community. Now Jenkins sex is, yeah, it's a sub project in Jenkins but it's pretty much is a community right now. And if you heard about CDF, you may see that these two separate projects from CDF standpoint. But again, if you are interested in about something specific in Jenkins sex, it's something we are happy to help organize. And then the development of this phase of promoting Kafka we should develop is in such a way that it's still back to a compatible way. It means after we develop the creative feature for this phase, I mean, the old feature will still work. Yeah, so from what I understand, from a remote for Apache Kafka plugin, it would be great to retain compatibility with what we have now. Well, generally, even there is real need to break compatibility, it's something which can be discussed with many maintainers with one in this case. But yeah, the retaining compatibility is always interesting in terms of Jenkins class system. So if you can do changes by, for example, introducing more extension points, more flexibility to components, it's something which is recommended. Okay. So if there is nothing else about this project, I suggest continuing in the chat for it specifically. So I'll probably mute myself on the call. And Martin, you can just continue the discussion and I will make sure to join the next meeting. Okay, thanks Oleg. Yeah, thank you Tom. So I'm still around to keep the recording, but most likely you'll be missing what has been discussed. Okay. Okay, so are there other questions related to the organization related to the process, how to join, how to participate, et cetera? Okay, so it sounds like there's no questions related to the process or to participating in summer of code. So then I would like to open the floor to questions from students regarding their specific proposals. But for that purpose, I would like to give the opportunity to people who are new, who have our first time joining or second time joining the call to speak first. I can go if nobody else wants to. Okay, so the project that I was interested in is the plugin installation manager, CLI tool slash library. And so I read the doc, so there's like these different existing implementations. And so, and then I think that I was just a little bit confused about like kind of, so the goal of this is to basically try to have a lot of these plugins installed before Jenkins even starts. Is that correct? Let me quickly look at the project description here. I think you're right, that's the general idea is to be able to install plugins from the command line sort of before Jenkins goes to production for its users. Okay, and then, so I saw, okay, so I like installed Jenkins and then I also saw that there's some kind of new to Docker too. So you can also install like this Docker image of it. And so I was kind of wondering like what the difference between the two is and like when you would wanna use like this Docker image versus installing it other ways. Okay, so I'm not too sure. Well, obviously there's a difference between Jenkins and a Docker image and Jenkins sort of standalone outside of Docker, but the difference, it's not major, it's more the way Jenkins is packaged. So I'm just going over the, let me share my screen, I'm going over the project description here. So there's existing implementations. Okay, there's official Docker images, configuration as code. There's also a REST API for installing plugins. Let's see if it is mentioned here. Yes, so there's a REST API for installing plugins, which means plugins could be sort of written like the list of plugins could be written as text, input, and then a script could read that list and simply call the REST API on that list. But that's fairly simplistic. It's, we cannot say that it's an entire project like that. So who are the mentors here? Baptiste and Oleg. So have you tried pinging Baptiste in the chat? No, not yet, I'm still kind of getting into this. So yeah, I can do that next. Yeah, absolutely. So, and this is valid for all the students. Do not hesitate to ping the mentors that are listed in the project documents. Yeah, they'll have a really good, they'll be able to clarify a lot of what they're asking and maybe help kind of you generate your proposal. Okay, thanks. So maybe it makes more sense for me to just interact via that channel and I can get, like if anyone else has questions, they can go ahead. Okay, thanks. Okay, so like now can I ask a few questions regarding build discover, Martin sir? Yes, let's try to keep it to 10 minutes this time and to make sure we have time for the other students. And go ahead. Yeah, okay, so like I would like to share my screen. Yep, go ahead. Like, yeah, so like I have a few doubts in my proposal actually. I hope my screen is visible to all. Yes. Okay, yeah. So like first of all, so like as you clear that keep forever the feature should be there in all the code, right? So like what I am proposing the proposal is, yes, it would be available in the plugin. So like that feature would be there in the plugin and it can be used anywhere where the user wants to use. And I have added this compatibility feature in this synopsis part so that you know, it could be there at the first of the proposal. Yeah, yes. Thank you. Yeah, so like now I can resolve, yeah, okay, thank you. Then, okay, yeah. So like there was a doubt that, what do you mean by four parts, right? Four actions. So like what I am doing is that this project, like I am just dividing this project into the four parts, like the first part can be a part of complete filters and the actions and all that job, and you know, like all that coding. And after that the second part can be the integration of that all filters and actions with the external workspace manager. Then the third part can be just adding like just integration of this plugin with the, with the multi-branch pipeline. And also adding the feature of build that leads to production load, like terrier, you know, so like here there is no four extensions and all that, but you know, I thought that, I thought that there would be a lot of things that could be done in the same way. Four extensions and all that, but you know, I thought that this can be the four main features in which I can just divide my projects. So, and- Yes, I understand. I wanted to clarify and you have clarified it. So that's good. Yes. You can resolve this. Yeah, thank you. My comment here, I only have one comment is there's three coding periods. And now you have divided your proposal into four sections, four parts. So you might find it easier to try to divide it in three parts, but it's up to you to assign the parts to the coding periods. It's up. Yeah. Actually what I thought that there are three coding periods given, so I thought that I should divide my timeline accordingly, rather than my project parts. And that's why I have, you know, made timeline according to the coding period given to us. That is phase one, phase two and phase three. Yes. So like, it's just like- Then I can also change my timeline It's just a comment I have. You might find it easier to organize the projects in three parts because there's three coding periods, but in the end it's up to you. This is just my thing. Oh yeah, sure. You don't have to split it in three parts. That's just a suggestion, but it's up to you. So you can do what you want. Well, so like I'll just merge this part of, you know, a feature of that build side lead to production. I'll just add this part to the first feature of like, you know, the main plugin part. So like I'll just continue the third part here only so that it can be, you know, go together. And so- Something new. Yeah, sure. I'll just do that. Okay. Yeah, so like I'll just end it. And, okay. So one more question. Yeah. So here it is. So like you have a given a suggestion that the advanced build discoverer can be implemented as a base filter class and we can have many class of different filters and different actions, right? Yes. Oh yeah. So like what I've done is that I have added both the ideas that different classes can be made of filters and the actions and also different methods can be made of like both of these so that we can just decide a concrete way in the community bonding period. Okay. So like I'll just resolve this comment right now. I hope it is fine. So in general, when you resolve comments, try to try to put the incorporate the discussion in the document itself. So for example, this one. Yeah, so like I added this one in the proposal. Right, but it's not added where the comment was made, but that's okay, it's there. So like I just want the implementation part to be more clear like suppose if I will just add this sentence after this, then there may be confusion to view the mentors like what exactly I need to do is not much clear different to me. So that's why I've written them in two points that one way is to make classes and one way is to make methods. Yeah, that's fine. You can resolve it. Yeah, yeah, thank you. So like yeah, this is also I think much more clear that actions are not in the filters and the filter and the options of filters will be given to the users followed by the option of actions. So like yeah, so this is not the final UI. The final UI will be a dropdown menu, but like first of all, like filter one can be selected like number of bills or number of days and followed by that, the user need to choose one action that he need to discard or not to discard. After that, the user need to configure filter two and after that, he need to configure the action two. So that actions are not involved in the filters and both the choices are given to the user so that he can get more flexibility about his change. Yes. Yeah, you can resolve that too. Yeah, thank you. Okay, yeah, so like now I think that's also consistent so I can, what one notice that yeah, so here you just ask that please present the pipeline DSL index for the show. Do you mean by that? Should I give some pipeline code samples in the proposal or like I am not much cleared by your comment? Yes, if you can provide some pipeline examples of what you think it will look like in the Jenkins pipeline. That's gonna help you a lot with regards to defining what needs to be done. Okay, yeah, sure. So I'll just add that and yeah, so like now here you have undoubted multi, like so yeah, so what actually I understood with my study was that some users define multiple work species in the Jenkins file and they use that work species parallely so now builds are created in that multiple work spaces. So now if a user just use a single work space then we can discard that build easily by getting the root directory by only just calling one method but if there are multiple work spaces defined in the Jenkins file running parallely for that I have written the implementation that we can use finger printing and by that we can get each work space ID and by using that we can get the path of work space and the other details through which we can just delete the builds from that work spaces. Well, yes, let me read this again. Yeah. Okay, it's your comment that I replied to where you say user can define multiple work spaces in Jenkins file that is fine and then you say, so we need to discard build from all that work spaces. So in Jenkins the build itself is part of the build history, it's also called a run or we can call it a build and it's these build objects after their run they become, they have a run wrapper and it's the build object that contains the work spaces whereas your sentence implies the other way around. Your sentence implies that work spaces contain builds. Work spaces contain build data but build objects contain work spaces. Actually build objects have a reference to the fingerprint and the fingerprint, sorry. Build objects have a reference to work spaces but there's also the but work spaces are registered with fingerprints. So let's say two builds share the same workspace then if you delete the build you cannot delete the work space because there's another work space that refers to that, there's another build that refers to that work space, does that make sense? Yes. So I just wanted that to be clear. Okay, so can you just tell me where I've written that the workspace includes the builds like in the comment or in the proposal I have written? I can't find it. You wrote that in the comment right there on your screen at the top, oops. Oh, okay, yeah, so you said okay. So when you discard build, okay, okay, yeah. When you say need to discard builds from the workspace it sounds like the workspace contains the build. Okay, yeah, yeah, yeah. That's what confused me, yeah. Oh, okay, yeah, so like I just cleared once more that yeah, so like for deleting a build we need the data of its root directory, right? So and for that we need to data of that workspace. So and that's why I entered, you know, and like that's why I wrote the fingerprinting implementation through which we can get the workspace ID and all the other details. And by that information we can, you know just delete the builds. So yeah, like I think by this implementation we can delete the workspace and the builds too, like what I think is, I am not clear but what I think right now is that we can discard both the workspace and the builds both by this implementation. Okay, so maybe you want to clarify that a little bit, clarify the wording a little bit in this paragraph. Maybe, yeah, yeah, since, yeah, okay. So there's six minutes left to this specific call. There's another call at 11 for students. So I will remain on that call but before we end I just want to make sure that everybody has a chance to ask additional questions. So Nisarika, if you could, we can take it offline or I can help you a little bit later. Just want to make sure everybody has time to show. And if no one speaks then, okay. So let's just, I don't know if Lee Vu or Vutwan or Yunchon have questions or maybe Arnab. Oh, nothing from my side, Martin, thanks. Okay, yeah, so like Martin said, can we just have a, you know, separate meeting for this discussion if possible, like because, you know, I am mostly done with my implementation part and only I need to, you know, just clarify a few things to the mentors, which is written in my proposal. So like if possible, and if, you know. Can we use the next office hours which starts in a couple of minutes? Yeah, yeah, sure. Does that work for you? Yeah. Okay. So I see that Prasthik just joined. Hello, hello sir. Hello. So actually I wanted to ask questions regarding to the Artific Promotion plugin. So can I ask this question to you or should I wait for Oleg sir? Okay, so who are the mentors on that one just a second? The mentors, actually the mentors are not present right now, so. Okay, have you tried pinging the mentors Klaus, Mike Long and Oleg for this? Yes, sir. I have pinging the Mike Long sir. So like should I schedule this QA session for the next session or like should I ask right now? You can ask, I'm not sure I can answer. The best people are the mentors, yeah. Okay, like actually I'll just like ask like a small fraction of what I will be asking in the next session, like it is a UI implementation. Like it also like this project resides also heavily on the UI implementations. So I just wanted to confirm, confirm that my project that my UI vision is correct. Just it will just take one or two minutes. So can I show that to you? Yes, I don't know if I can answer properly. Okay, I'll just share my screen. Okay. Okay, so is it visible? Okay. Yeah, I can see your screen. This is the like the home base of Jenkins, right? So like, for instance, if I introduce the new like promoted plugin that supports both the pipeline and the freestyle projects, then like how like Oleg sir has said that I should be creating a new job for that new job for the promotion itself. So would it look like this? Like I just go into the new item section. So is it visible? Yeah, I can see your screen. Okay. So I just go into the new item section, right? Okay, so like there's an enter an item name, right? So if I introduce the new plugin, would it be the case that they would be like similar to the freestyle projects, there would be something like promotion plugin or like promotion, promotion of artifacts, like a simple, a different kind of job? Like would it be, would it stay in this section that I wanted to ask? Like he said that we need to introduce a new job. So like new job, that new job, would it reside in this place? Like... Okay, just a minute. Let me, let me look at the proposal itself at the project idea. The proposal says that like get, get rid of all the building promotion plugins and introduce a new standalone plugin. And I discussed this thing further with Oleg sir. And he said that you need to introduce a new job, an entirely new job. And I just wanted to ask that, would that new job be residing at this place? Like... I think the answer is yes. Okay, like for instance, I just go into the main section, I just build a project. Okay, I just create a new item. I upload all the necessary codes. And just when the time comes after the build, if I want to promote things rather than going to the configure section and promote builds, would it be the case that I would go into the job and promote the builds? Or... It sounds like it. Yes. If it's a separate job, then the job has to run to promote the builds. Like this, this is build hashtag one, right? So this is the first build. Like if I want to promote this thing, like I'll just go into the promotion status. Promotion status. Like inside configure. Oh. Internet is really slow. So I go inside the configure section and promote builds and give all the necessary conditions for upstream or downstream conditions to promote the build, right? Like this. Well, that I'm not sure. Like this promote builds when this section, this section would just be shifted to the next job. Is it what it meant by the proposal? Like this promote builds when this all section would be migrated to the new job? I think yes. Okay, like... But you should really be checking with the mentors on this. Okay. Last question is like job literally means the project, right? New item means job. It will translate to new item. Or is it there's something, are there something like job inside the code? Job literally means like projects, right? Yes, okay. So in Jenkins, in terms of terminology, job and project mean the same thing. It is something you can run, something you can execute. Okay. And then to complete the terminology, when people talk about builds and runs, they talk about the specific builds of a given project or a given job. So builds create a build history and the jobs are definition of a generic definition for all the builds it can produce. Okay. So it would mean the same thing. Create a new job, new section where the pipeline and the freestyle projects will be accessed. Yes. I think what you were showing earlier and the new type of job, when you click the new item, it would be a new type of job and the type would be promotion. Okay. That's right. From reading like the first 10 lines of the project idea. Okay, I just wanted to confirm this thing because if the UI gets screwed up, then like the backend won't work. So that's why I just wanted to confirm this. So thank you, sir. Thank you very much. I'll confirm this in the next session with Olexa. Okay. Thank you. You're welcome. Okay. So I don't know if Olex is gonna join to end this session. I think it's best if we find a way to end this call and start a new call except I'm not sure how to start the new call yet. I have some notes here on how to do that. Okay. Sir, won't be joining us in the next QA session. He will not. Will he join in the next session, Olexa, my mentor? I'm not sure. I think he said it'd be back. Okay. He just said I will. Okay. So Olex, do you want me to end this session right now and start the new one? I think the next QA session is after one hour. Oh, there's another hour? Oh. 4PM UTC was the exact time. Sorry. We will have another session in one hour. We changed the daylight time here. So just a minute. I can only attend the first 45 minutes of the next session then. Okay. So anyway, I will be able to direct the entire session and we will be able to discuss the remaining topics today. Okay. Thanks a lot to everybody for participating. And yeah, again, please use the maintenance piece and Gitter to ask technical questions. It will be more effective. And yeah, let's use the sessions mostly for the remaining questions and maybe some project specific tasks, but just as a lot of results. Okay. Thanks everybody. Okay. Let's stop the broadcast. Thank you.