 tributing, especially for Google Summer of Food, and my project was semantic versioning plugins for Jenkins. So that's actually why I started joining Cloud Native SIT, but now I've been interested in Cloud Native and infrastructure SITs in general, so I'm attending. Great, welcome. Thank you. Do you have any questions on your on the project you're interested in on your proposal? Actually, after submission of my proposal, I was one contributor commented on it, and I had questions related to that that I wanted to ask. So if that's fine, I'll go ahead and ask them. Yes, please do. Actually, just a second. Okay, yeah. Welcome, Naveetya. Um, would you like to introduce yourself? Hey, welcome. Yeah, hello. Hello, everyone. I'm Naveetha. And yeah, I'm currently just draft map. I just posted my proposal in GSOC and I'm just here to listen to all of you. Great. On on the cloud events plugin. Very nice. Yeah, yeah, on cloud event plugin. Yeah. Excellent. Yeah, thank you for your proposal. We were so pleased with the proposals. They're looking great. So it's great to have you're involved in and your interest. So thank you. So it'd be okay if I go ahead and share my screen so it would be easier to share it with everyone else too. Yes, please do. I hope you can see the screen now. There might be a slight delay. It says you've started screen sharing but it is black. Okay, here we go. My laptop froze, I guess. Weird. It's alright. Actually, this problem happened earlier also when I was screen sharing on Zoom. I think it's some version issue that I have of Zoom SDK. Okay, it froze. I would rather stop here. I'm so sorry for the issue. Actually, would you like to put a link in the chat? Yeah, I can share. Yeah, I'm very impressed. Right. Okay, so if it's scrolled down to page number four. Yeah, so Jesse commented saying that a similar plugin that does not exist in Jet 229. So and we had this in our mind that it exists and will replace it with Jenkins. So actually, that is not true. Then the half of my deployment part of the project becomes wrong, I say, or invalid then. Okay, yeah. So, do I need to revert? No, so, so JX, JX release version is a plugin that for JX and it is available, but it can also run as a GitHub action to determine the next version. And because it's run as a GitHub action, it's possible to integrate it with a Jet 229 stuff. It's not by default part of the Jet 229 stuff. But I could see it becoming that in the future. And it's it's a bit up in the air because the current method of versioning with Jet 229 uses like the number of commits since origin and a GitHub to produce something unique. And unfortunately, it produces non semantically versioned or non semver compatible versions. So it means it's kind of quite, it's not very useful for plugin developers. If you're developing a very, very simple plugin that never requires backporting or fixes or anything like that, then it might be absolutely fine to use this always incrementing number. But most of the plugins that are classed as like tier one, tier two plugins for Jenkins, you have, they have to provide backports for them when there are fixes that need to be done or security releases. So and they are probably semantic versioned. So I think they need a different way of doing it. We've heard the mark that like certainly on the get plugin switching to your Jet 229 has is is not going to work for them. They need a they need a way of doing semantic versioning. Okay. So I mean, he's also right. And we are also right. So yeah. Do you? Does I give you enough information to to move ahead with this and to think about how the work you're going to do? Do you have any more questions for you? Yeah, just one second. I think I have one more question. Great. So it's on page 15. I'm so sorry I'm making you know, I love it. It's great. This is excellent. Yeah, this comment. So of course, as far as I understood it, that's like we are complicating or what I'm proposing is a very complicated approach and rather simple skill I do the job. So I actually did not include that in the proposal and it can be done as simple as I do. So shall we modify the approach or I shall shall I add that thing in the timeline? So that that is about writing. So whatever file that you potentially read the version from that is about writing the version back into the file as like an optional thing. Right. Yes. So yeah, that I mean, that's valid. We will need to we need a way of doing that. There will be certain builds that will want to have that in place. At the moment, I mean, you could do it by extracting the version out and running a Maven set version to explicitly push that back in if it's a Maven POM. But I would thought that there would be that's an extra step and it would probably make sense to just do it in a single pass. So like writing back into the POM file or the gradle file is not needed and writing a text file where the way he's suggesting that is. So I actually I think you'll probably want to do both. Like you may find that you you may find that. So within the context of building, for instance, Jenkins plugins, they're either gradle or Maven and they're pretty straightforward builds. You could write writing and or updating the POM would be fine, creating a tag would be again also would be fine. It's pretty simple. But what we're seeing is the use for this in like more much more complex builds where you may be wanting to trigger a make file or something else or another process you may need those variables. So writing writing a file with the version in is going to be handy for some people updating a file that you've really or just echoing it to the screen that also might be useful. OK. So providing support for everything and then asking the user what he wants is the idea. Yeah. But. I think there probably is some confusion around so when I created the proposal, I created it as a semantic version and bugging Jenkins, but there is already a semantic versioning plugin for Jenkins that seems to do nothing to do with semantic versioning. I think it just passes the version. That's all it does. So OK, I would probably go with like maybe I don't know what we do with that. Actually, I don't know how this works, Cara. But would it make would it simplify things if we could rename the proposal slightly? So Conventional Commits plugin, I think we we have space to alter. The work that is done, I don't think we can rename it under Jesus, the proposal is now submitted and that deadline is passed, but in this community bonding period, of course, you know, the understanding of the problem space, the exact work that's going to be done, that that's fine for those involved. Does that make sense? Yeah, I like so there was a bit late. That's good. Thanks for being here. We're talking about a semantic versioning plugin for Jenkins proposal for GSOC and going over some questions. I do not have any more questions than the final one would be that shall I rename the document over here or not? And if it's creating confusion. I think the document makes sense. I would probably leave the document as it is because it it it relates to the proposal. But maybe we need to add some text into the proposal to say like this is also known as the Conventional Commits plugin. Yeah, I'm just sorry. This is very good. Yeah, just to clarify the current state with GSOC, the proposals have been submitted on April 13th. And it means that basically you have a final version. You cannot modify it anymore. And as we discussed at the office hours on Wednesday, we will be basically making decision and reviewing the version of proposal submitted on April 13th. If the proposal gets accepted, if you have a project, then they will become a community bonding period of three or four weeks this year, where you will work together with mentors to basically convert this proposal to the design specification, etc. And all these comments, terminology issues, etc. can be addressed there. So, for example, when we publish a project page on Jenkins.io, we can apply another name and we can even ask Google support to change the name on the GSOC website, though usually people don't do that. But yeah, until the project begins, may basically whatever you change is just preparation for the next phases if the project gets accepted. Sorry if my comment was a bit out of context, but usually when we talk to students, they want to modify proposals later. Oh, no, no, it wasn't out of context. I said, it's okay. I understand. Yeah, so right now you're welcome to do anything in the Jenkins community basically as common contributor if you want to keep enhancing your proposal, etc. You're welcome to do that. We'll just review the version which was submitted. But yeah, after that, these comments can be integrated into the plan. Thank you, Gareth, for helping me. I have no more questions. And Mavitha, I'm sure I missed your name. I am so sorry. Would you have any questions for us on the GSOC process or the proposal? Yeah, I have, but now, yeah, I have not cleared that yet. We have to continue working on the project in the community to more into this. And do you have a good sense of how you want to move forward in the coming weeks in terms of engaging with your proposal or with the community? Sorry, it's never an issue in my side. Can you repeat it again? It's really good to get to it. I just wanted to make sure that you had a good sense of how you wanted to move forward in the coming weeks, with either the work on your proposal or other contributions to the community or if you had any other questions in general about Jenkins or GSOC. Well, don't hesitate to ask in the GITR channels. And we welcome your participation. We're very excited about GSOC. So thank you both. Yeah, just one side note. So if you don't know exactly what to do with regards to GSOC in the coming months, one of the things you could consider is basically focusing on your study, finishing up, whatever tasks you have there. Because if you get selected to GSOC, then you will be able to dedicate more time. And if you don't get selected to GSOC, again, it's something that is useful for you. So our recommendation is basically if you can address basically whatever questions you have in this semester, maybe you could start from that because it will also help you in the future. Yeah, again, it's side note. Okay, well, if we do have any more questions about GSOC, it was there, were there any action items or things you wanted to bring up about the Tecton client plugin, Gareth? No, yeah, about the Tecton client stuff. So I don't, they believe we've got any proposals for that. Yes, that's true. But I'm in general. I know that James Smith appeared to that this morning. I was gonna look at, no, I'm not sure what the current status on that is. It would be really good to get a, get it working in a pipeline with the form of enter and test so we can kind of cut a version one release or something that's less of an alpha release at least. Yes, okay, excellent. And Oleg, did you wanna give any updates about the Kubernetes operator plugin? Kubernetes operator, not a plugin. Okay. Yeah, so just a quick update on the governance side. One month ago, we voted for accepting the project as official Jenkins sub project. So it was a great time. It was effective on that date. After that, the virtual lab team, they made some updates on the websites and they also created a request update, Jenkins IO. So it has been landed. And yesterday, we have published an official blog post. You can always find it in LinkedIn. We will also do something about Twitter within the next few hours. But yeah, the project is now effectively a part of, well, Jenkins project, like it was before, but in more official status. We will also work with the team to integrate the Jenkins Kubernetes operator into the roadmap. There was ongoing, there was a discussion about open governance for the project, which kind of fell apart because Red Hat decided to proceed with its own operator at that point. But we will need to recover this discussion and to see how we could improve that. Yes, what is the relationship between Red Hat's work and what, yeah. Okay, so let's say Red Hat's operator. Right now it's a hard fork on Jenkins Kubernetes operator, which is no longer fully compatible. And it evolves in a different direction. Why it happened? Because Red Hat has its own interests, mostly on the open shift platform. When they were trying to contribute to Jenkins operator, it wasn't possible to integrate changes because maintainers were not available. Then there were disagreements on the roadmap. We tried to mitigate it in the Jenkins governance board, but they're getting cold sides in the discussion. We offered the open governance proposal that was supported by Red Hat, by the Jenkins governance board. But first to slap at the point was not available. So finally Red Hat decided to proceed with its own operator and again, we as Jenkins project supported that. So right now there are two operators. One is called the Jenkins operator, which is now official sub-project. Another one is Jenkins automation operator, if I recall correctly, or something like that, which is basically Red Hat's project. It's been developed again as a part of the Jenkins project. But yeah, these operators are not compatible with each other. So this state is not optimal from the community standpoint, but yeah, that's what we have. Okay, thank you for your update. And I still want to sync up with VipHaf, Akram and other contributors from Red Hat to see what we actually plan for that. My understanding is that they are finding with the current status quo, because it also allows them to focus specifically on the open-shift ecosystem. Interesting, okay. Great, any other topics that you all would like to bring up for discussion today? We're at the half hour. Okay, well, we're at the half hour. Thank you all for being here. And again, thank you very much for your GSOC proposals. I'm very excited. All right, have a good rest of your day.