 And there are other awards and nominations that Continuous Delivery Foundation has. You can see them on their award site. And it gives a nice overview of the awards, what they look like, the different projects, and how this is all gonna look. And the winners are announced at CD-CON. So this year that will be announced and people will be presented with their awards at CD-CON itself. Voting is gonna open up on Wednesday, March 8th. So same day as our LTS release. And then voting will be open until the end of March, when it closes on Tuesday, March 28th. And then from there, the results will be right at CD-CON. So by all means, if you have a chance to have some time, think of someone in between now and tomorrow that you wanna throw out a nomination for. That's amazing, please do so. Everyone appreciates it. Next up, this is something that we've been discussing lately is the documentation transition to Java 17. So with the April, May, 2023 release of Debian 12, it is not going to come with Java 11. It'll be released with Java 17. So when this happens, we're going to transition the Jenkins documentation to reflect that and utilize Java 17 for installation and other documentation purposes. This does not mean Java 11 support is ended or dropped in any way to be performed. That will continue. But Java 17 is available fully functional and supported since Jenkins 2.361.1. So we wanna encourage people to transition sooner than later and get ahead of the timeline that we will eventually be in. This will also provide a consistent Java version and again, more functionality to users as they move to Java 17. So it's a benefit for everyone involved ultimately. And I have emailed Tim Jacome as the release officer to let him know about the transition. He responded already saying that everything sounds good to go. So no surprises to be had and just an easy win for us there. And then the next note is about improving the end of life notifications. Now, Mark, I wasn't at the Platform SIG meeting. Would you be able to share more about this? Yeah, so, well, and it's the idea has gotten even a little more refinement since the Platform SIG discussion. So I was in a discussion earlier today with Batis Matus and with a few other people and Batis had what I thought was a really creative idea. So his suggestion was maybe what we do is a directory that we look at every file in that directory and treat each file as a data file and that data file could contain the thing that we're telling about its end of life and the end of life date and what message we should say after end of life, what message we should say before end of life. I mean, there's a lot that we could do with this concept of trying to, hey, I want to actively tell people this thing is going to be end of life if you have it. And the presence of this file on the file system would say you have it. So when we create the alpine, when we create the blue ocean container, the terminal blue ocean container as an example, we write this file, a file to this directory that says this container is ended. It's time. When we do that with CentOS 7, we write another file which is CentOS 7, end of life for the Jenkins project is this date, et cetera. And for me, the idea of, oh, you know what? A general purpose admin monitor for those kinds of things that can be informed by the presence of a file on the file system. Now, that's not everything, right? Because we can't, there are things that we can't detect simply where we don't control the file system of the thing we're creating. But containers, we absolutely control the file system. And so why not use it there? There are other possible places like that where, you know what, we might choose to have other things write, for instance, Java 17 end of life or Java 11 end of life will eventually come. The day will happen when it is end of life. And we might use this mechanism to put that in there so that the end of life message has a little bit more intelligence of being, hey, you're before the end of life date we'll show you this message where after the end of life date, we'll show you this message. And Bati's point was, this is probably a good idea for a small, relatively lightweight Jenkins enhancement proposal that brings the idea for discussion. And then we use this Jenkins enhancement proposal to discuss the idea, get people's insights. Then we do a pull request to Jenkins core saying, here we did this plan. So I think I'm gonna go ahead with it. It'll be a while because it takes me a while but it's a good fit matched with the CentOS 7 accelerated end of life idea that I've got. So the idea there is, I wanna kill CentOS 7 but I need the way to tell people that CentOS 7 is going away here, here and here and this mechanism may be that technique. So that's the idea, did that give enough orientation, Kevin? Yeah, that brings me up to speed completely, frankly. So that's all very, very clear for me, Mark. Thank you. Now Bruno, was there anything else that we talked about in platform SIG that I might have missed? No, I don't think so. Oh, thank you, Mark. And so just something that I had in mind as you were talking, Mark. So maybe including just like a partial directory of the messages that we can share or just a couple of different messages that we could kind of use as a template for the different pieces or... Yeah, and I think you've got the right concept and I'm certain that the idea is not fully vetted yet. I know that there's more thought that has to go into this. Should the data files be XML because everything Jenkins does is an XML. Should they be YAML because people are more comfortable writing YAML? Should they, which field should they have? What should we do with those fields? All those things are absolutely vital but they're also why we use a JEP, why we use a Jenkins enhancement proposal to do it because then that's a place we can express those things and let other people then give feedback. No, that's a bad idea. You should do it this other way instead. So Mark, you think there are some people which are who are comfortable with writing YAML? Wow, I didn't know that. Oh, no, no, no, no. You really don't want to get me started on the hypocrisy of space sensitive data files when people harangued me, gave me a terrible hard time about my love of the Python language with its space sensitive syntax. I do not want to, yeah, absolutely YAML. It is what it is. Space sensitive data files are just as interesting as space sensitive languages. Thank you very much, Mark. Appreciate the explanation and clarification. And before I move on to the next thing on the agenda, I just wanted to welcome in Monica. I saw that she joined while we were in the middle of that discussion. So welcome Monica, hi. I hope you're having a good day today. And yeah, if you have any questions, we'll absolutely please feel free to share and we can answer as best we can. Hello. The next thing on the agenda was the end of life checklist that we have started to discuss. So in line with what we were just discussing about the end of life notifications, we do have several items that are coming up for end of life relatively soon with Ubuntu being first and at the end of April, Ubuntu 18 specifically, sorry. And so the checklist that we're thinking of is to make sure that we're looking in the right repositories, packaging sites, any sort of container images, jenkins.io and updates.jenkins.io, just anything that we could potentially find this information in or search for, we wanna have a checklist so that we can just make sure everything was taken care of and that when something is end of life, we know for sure that the documentation in the rest of Jenkins reflects that. So this is something that we're just continually working on at this point in time. We haven't, it hasn't manifested into anything super constructed just yet. But as we're going through, as we get to the point of looking at the end of life for CentOS 7 specifically and these other products where this is going to become more real and more literal in the sense of having a template or a checklist to work through. Kevin, sorry to interrupt. Yes, I'm just wondering for your checklist content ideas, do you think of automating? Well, you know, when you will spot a place in the documentation where we are referring to a version that will go end of life soon, should we modify the documentation so that we put just a little bit of automation so that whenever we'll change the version, then we won't have to come back to that same piece of documentation and putting it up to date once again. So, Kevin, if you're okay with me injecting, we've actually got automation somewhat like that already in a few places. Yeah. And so for instance, the choosing the right Jenkins version to build against, so choosing the right minimum Jenkins version is data-driven, is data-generated. But it requires custom work to do that. And for me, the challenge is the custom work, is the update often enough to justify inserting automation to replace the human effort. And these operating system end of life are so infrequent that, well, the same question applies to the Jenkins release checklist that we use, right? There are many of the things in that activity which could be automated, but are not automated because it's so rare that we do them once a week or once a month that we just don't bother with the automation because the time savings will never be recovered for the automation cost. Got it. It was the worst best idea of the day. Thank you. I've had worse, don't worry about that. Also, and this is just what I was thinking of, in my head, there's contextual text around what references we need to update potentially. And if we automate those, just like that version update, we would still have to, like someone would still have to go back in and update the text around it if it needs to be changed in that regard. So the automation would definitely be possible and like Mark said, we have it elsewhere. I know I've seen Alex Prendes do a lot of automation and changing of things recently with links for instance. But I mean, if we can take one thing out of it, maybe it's something worth looking into. I feel like I would just do it manually myself anyway because I'm a stickler for that sort of thing. But it actually makes life easier, I'm not opposed. So yeah, and as Mark had said, there is a release checklist for the Jenkins LTS releases that we use. So this would be a great template and basis to work from. It's already something that we're familiar with, we're using and has helped with the releases in the path up to this point in time. So yeah, that's something that we're gonna probably use when we go to make the checklist. Sorry, Kevin, I have no question and a remark maybe. Do we know the definitive list of all the OS and tools packages we depend on or is it written somewhere? For example, Ubuntu something, Alpine something. So if there are a text file or a data file somewhere which lists all our dependencies. Can you give more context on the dependencies questions? Yeah, sorry. Dependencies for documentation creation or dependencies for Jenkins Core or? Globally for all Jenkins Core, yeah, Jenkins Core and documentation. In fact, I was just wondering, you know the other day, Mark, you told us about a great open source website which lists the end of life of products and operating systems and so on distributions. And I was wondering if we could generate some kind of bomb. I don't know if the term is right, but you know, all the distribution version and so on that we are referring to in the documentation. So that's when we make a request to the API of this website, we could then know that something has changed and that maybe a human being should modify the existing documentation with that. Just by looking at the file which has changed because of the API changes, I don't know if I'm making myself clear, I'm not so sure, but yeah, I can see your face, Mark, maybe I've made a point. No, no, I think so, for instance, by the way, Kevin, it's endoflife.date. Ah, okay. Yeah, there is another one which is a commercial one, I think, but yeah, date, no end. I thought that was just a minute. Yeah, this is the page. So, but the data that generates this site is very much readable. And so I think your point is an interesting one, Bruno, it could be that, well, although I don't know how the, yeah, I mean, I think what you're saying is, is there a way that we could have our own reminders that something we are mentioning is in fact, approaching end of life because they will reach end of life, right? Every one of them will reach end of life. And if we reference something by version number, should we then have a way of knowing when that end of life date is approaching? Thanks a lot, Mark. That was my idea. You're a great proxy for my ideas, thanks a lot. Yeah, unfortunately, I don't know how to do it, but I think it's an interesting idea. I think it's worthwhile to say, okay, could we find a way to annotate documentation that says this is a reference to, and then maybe it's a reference to a page on the end of life date site for now, for instance, whatever. And then, okay, check that site. Are we about to end life, that kind of thing? Yeah, good question. Thank you. And I know that last time we took a look at the end of life date site here, they do have their API guide, so it is connectable at that point. And so, like Mark said, I think there's a real possibility there, and it would be neat to have that sort of automation there as well. I don't know how to do it, but yeah, that sounds really neat. I like it. Thank you. Any other questions for you, or anything, comments, concerns? No, no, sorry, I'm still there. No, you don't have no apologies, Nester. Okay, now next up on the list, so again, prepping for the CentOS 7 end of life, as Mark mentioned, this is something that we're trying to encourage a lot sooner than later. There are lots of reasons to do this, most of them have to do with just the older, older configuration settings that CentOS 7 is looking for, such as the command line and SSH versions that they're using. And the Docker container has been deprecated since September 2022. The entered maintenance back in 2020, and its official end of life is in June 2024 from CentOS. So it does make sense to start moving towards this now, as opposed to later. There's some of the replacements that we have listed here, Alma Linux, Rocky Linux. Some of these have been added to the documentation already by Mark, so there already is presence there, and it's just a matter of going through and taking care of the rest of them. And Mark's gonna submit a Jenkins enhancement proposal to get everything kind of focused and connected, and so we can submit our feedback, potentially get a blog post written, as that is going to be necessary for everything kind of just moved away. But we're not good. Oh, no, wait, I just, I, something happened, anyway. So the JEP will have things like blog post ideas, the timeline that we're gonna be looking at, what kind of warnings we're gonna have to provide to users and the explicit end of life date. Mark, is there anything else that you'd like to add to the CentOS 7 information? No, just that it, I think it makes sense, and I'm gonna, I'll go ahead. I don't yet have an idea of when I'll start this, but it feels like it's a good, given the platform SIG questions from the security team about, hey, can we get rid of some of these old container images and this is one of those examples, there's plenty of motivation for this idea, right? There's plenty of motivation to say, look, let's admit that we have neither the interest nor the capacity to maintain CentOS 7 amongst Jenkins contributors. And we get to decide what we're willing to support. And I don't know of anybody of any of the Jenkins contributors, Jenkins active maintainers who are interested in maintaining support for CentOS 7. And there's at least one that is very interested in not maintaining support. Ooh, okay, two. Well, that's good, at least we have buy-in on that then. Great, so thank you very much, Mark, for the additional context and information background. So that's something that will be coming up sooner than later, hopefully. All right, now I have to drop off, Kevin, thanks so much. No worries, Mark, thanks for joining. Take care. And yeah, so we're coming up against time, I'll wrap things up here. We just have a couple more updates. The first thing here is the Google Summer of Code preparation, so the Google Summer of Code status page has been updated to share our 2023 participation announcement. We are hosting the weekly Google Summer of Code office hours. I have linked here the Jenkins.io events calendar since it does have the sessions on here. And you can add it to your calendar right from here. So right there, copy to my calendar, the Zoom meeting links available and the Google Doc for the notes. So if you have questions or anything that you'd like to check in with about Google Summer of Code, you can see all those sessions that we have in the Jenkins.io events calendar. And this is scheduled out for several weeks. So you can see just where everything is. The specific projects may start scheduling their own sessions, but that will happen once things get started and the project leader will let you know. And then for the site generation for Jenkins.io project, Rajiv, who joined the Docs office hours a couple of weeks ago, it said he's willing to mentor the site generation project, where we're gonna be using Antora to build Jenkins.io and allow Doc pages to be version-specific. And that's the biggest thing there is the version-specific documentation potential. Right now we just have either just kind of a general statement or it's making sure that it's something that makes sure that both the weekly and LTS are gonna work. This would allow us to cater our documentation more specifically to the different use cases and different versions that are supported. And then finally, something that's been happening coming up a little bit lately is adding books to the Jenkins.io books page. This is something that I personally have seen a handful of contributions in the last week or two about. And there is not any guidelines for this in the contributing guide. So this is something that I wanna actually add to the contributing guide and set some guidelines up for. This also would include stuff like image guidelines and how to best use images, compression, quality, size, all sorts of stuff like that. And then things like making sure that it's a summary of the book and not necessarily the blurb that is given out to websites that are potentially selling the book. We're not trying to sell it just providing this information and resources to anyone that wants to, that is interested. And they have been being submitted as YAML files which does not accept formatting like a lot of them are being generated with. For instance, on some of the Amazon book reviews that I've seen, they have bolded lists that doesn't translate properly in the YAML file unfortunately. So there does have to be some updating and changing and reviewed there, but the formatting definitely has to be a little bit simpler or more standardized. And that might include changing to the using ASCII doc partials as opposed to YAML files at a later point. I'm not gonna worry about that for right now though. There are way too many good contributions to start upending things like that. And then the last note here is for book cover images we wanna make sure that they're a high quality, clear and rendering properly on all size screens. That also includes making sure that these images are compressed. There's compressor.io, there's a bunch of different sites and applications out there and available to use where you can compress the image, retain the quality and make sure that it's a lot less heavy lifting for Jenkins page. Again, I'm going through a lot of the book submissions right now and reviewing and submitting feedback and doing what I can to make them a little bit more aligned and unified in terms of their presentation. Outside of that though, I truly appreciate all the work everyone's been contributing and submitting. There's a lot to go through and we're trying our best to get through everything but there's just, it's so much quality content to work through and sift through that. I wanna make sure that we're doing really, we're doing right by the user in terms of the reviews and suggestions and feedback we're providing. Everything should be constructive and it should be able to look at as a learning moment or filling a knowledge gap, something like that. There should not ever be any feelings of confrontation or inadequacy or anything like that. This is a learning environment. This is an open environment, open sources of name of the game. So outside of that, Bruno, did you have any other questions or any items here? No, thank you, Kevin. Yeah, sorry. Sorry, I'm not the host. No, thank you. Okay, no worries. I'm gonna go ahead and stop the recording here then. The video will be available in 24 to 48 hours and it will be posted on YouTube, the Docs Gitter channel and the community.junkins.io site. So multiple places that you'll be able to access and watch later. Thank you again to everyone for joining and I appreciate it and have a great rest of your day. Thanks a lot.