 Welcome to the Jenkins documentation office hours. Today is the April 20th, 2023 edition, EU US time. Today we have myself and Mark Wake. If anyone else joins us, we are more than welcome to invite them in on the agenda. So for today, we've got a note about the Docs office hours Asia, which is canceled tonight. Google summer code update, next LTS release information and next baseline selection. There have been Java updates from Tumerin, OpenJDK and Oracle for 11, 17 and 20. So lots of updates there. CDCon is gonna be held May 8th to 9th. Plan to transition the Jenkins documentation from using Java 11 to Java 17. And there is an issue and some more information we can discuss there. We actually implemented a success stories navigation link in the top menu. So thank you to Gavin Mogan for adding that to the components and header. Alternative ways to handle stale documentation pull requests. This is something we've been discussing recently and of life notifications in Jenkins core. Again, this is something that we've been discussing recently thanks to everyone who's been able to talk through this and provide insight onto what we can do here. And finally, the proposal and plan to have early end of life for Cento seven in the Jenkins project. Is there anything else that needs to go on the agenda or does that cover everything for you, Mark? That's it. Okay. So first thing on the agenda. So tonight, Docs office hours for Asia is canceled. Mark will be available. So for today that is going to be canceled. Next week it's going to be back to normal though. So Google summer code is really coming up to the starting point, which is exciting for getting going and socialization and everything. So Yiming Gong, who is a mentor who is a new mentor this year returns after being a contributor last year which is really exciting. They were able to, they were working on the Jenkins file runner project. So great to have them back in a different role. And then Google is going to announce the accepted contributors on May 4th. After that, we will share posts, tweets, LinkedIn posts regarding the accepted applicants and the announcement. So we will have our own communication there. And then the next day May 5th is going to be Docs or not Docs GSOC office hours to welcome the accepted applicants. So in the next couple of weeks we'll be really getting down to what this is going to look like, who's going to be involved. And we're very, very excited to enter that period. Next up, so we have LTS 2.387.3 coming out on May 3rd. So Christopher has sent out the release candidate email as of Tuesday. So it is ready to test and download. If you can spare some time and do that please do so, provide any feedback. And the change log and upgrade guide has been created and added to the checklist. So waiting on backports and anything else that might come up so that it's not a final product but a work in progress for the time being. I'll be keeping an eye out for any changes, hesitations, delays, anything else that might come up and we'll take it from there. On the LTS topic, so the baseline selection was actually due yesterday but we are now we're aware of it and this needs to be decided in developer mailing list. So expect communication for that really, really, really soon if not today. So we'll get that communication out there, keep an eye on the developer mailing list and the baseline selection will be figured out. Next thing on the agenda here is the Java updates. So within the last week or so, maybe the last couple of days it looks like actually, Timurin, OpenJDK and Oracle have posted updates for their Java version. So Timurin for instance is on Java, has Java 11.0.19, Java 17.0.7 and Timurin 20 which is really exciting. So OpenJDK and Oracle have had similar updates. Timurin just happens to be a really positive experience which is why we've got them listed here but all three of these links lead to release notes and updates for all of the different Java versions that are being provided by each company. So right here at the top 11.0.19, so downloads are available and release notes as well. Same thing for OpenJDK and they have all their information here, release notes, downloads and Oracle. Where again, they have all of the different release notes. So we can go into any of these, see 17.0.7 and actually get the release notes. And you can see here, this is just April 18th. So this week, important to note, obviously we want to make sure everyone's up to date and make sure that not only the documentation but all users are as up to date as can be and make sure that there's no issues. Next on the agenda, I just wanted to bring up that we do have CDCon coming up. So that's gonna be May 8th and 9th. Not only is that gonna be a wonderful opportunity and event to just meet up and appreciate continuous delivery but it's also gonna be where the Jenkins Awards winners are presented with their awards. That will also happen for any other awards winners. So CDF, TechCon, et cetera, et cetera but it's gonna be an exciting time. And we did publish a blog post recently from the CD Foundation sharing Jenkins theme sessions. So a handful of really nice sessions and keynotes to check out. Some are clearly Jenkins, like the testing hundreds of OS images but everything is gonna focus on continuous delivery and Jenkins to that extent. Mark's also gonna be giving a keynote panel or a part of keynote panel and sharing a different talk entirely as well. So amazing, fantastic. Thank you very much Mark for stepping up and being part of it and representing Jenkins. Thanks. Next up on the agenda. So we have been discussing over the last few months, transitioning the documentation from using Java 11 to Java 17. I've created a GitHub issue so that we can track this and I've gone through and explained the background of what we're looking to do. Java 17 is fully supported by Jenkins. So what we wanna do is transition the documentation such as installation and usage and Java requirements, stuff like that to use Java 17 as opposed to Java 11. And this is strictly because Java 17 provides more functionality, better testing and just overall support for development. Java 11 still supported 100% by Jenkins for the foreseeable future. And when that comes time to discuss end of life then we'll figure that out. But this is not taking anything away. This is just reassuring people that using Java 17 is the way to go. It's the way of the future. That is gonna be what we should be on soon enough anyway. So the idea is that we can transition and make this visible and known to people before that end of life approaches. People can migrate, transition at their own speed and we don't have to worry about rushing. This is inspired by the fact that Debian 12 when it does release will not ship with JDK 11. Regardless of when the release for that happens and regardless of what they do end up doing with it the idea for us to transition the documentation is gonna, this is still happening regardless of that timeframe for them. This is around the time that we had described and decided upon the April, May area. So we're gonna commit and go through with that. And here in the issue, I've found a few links that do have Java information that can be updated to use Java 17. A lot of it is the installing information and documentation but these are things that I have been, I've been going through the documentation to try and find any other areas. There was one that I found for the managing system D services that we can also include in there. I just need to put that link in this issue. So Mark, is there anything that like I haven't covered or mentioned or anything here that you'd like to make sure we have either in the issue or in the notes here? No, that looks good to me. I think it's the right approach. I mutated it to include check boxes in those items that way when we visited them, we know, we can check it off. Right, thank you very much. Appreciate it. And yeah, and this is something that I'll be working on continuously until we get this all taken care of. So I'm open to questions, support, suggestions, anything like that whatsoever. And yeah, we still have to get to the nitty gritty of it and figure out how we're gonna go about that. But the important things here are making sure that everything is tested and verified and that we're not providing any misinformation when doing this update. So yeah, we'll figure that part out Mark. I'm sure it's not as difficult as making it sound right now. Thank you. Yeah, thank you. Next thing I wanted to bring up on the agenda is that we now have a navigation link in the Jenkins.io header for success stories, which leads to the stories.jankhens.io site. This is something very recently implemented. Thank you again to both Alex, Brandes and Gavin for getting this implemented and suggesting this is great and something that we are really proud to share and wanna make sure that people can see that and know it. So putting it up in the header is just fantastic and it makes it front and center for people. So that's just something new, just keep an eye out for. Like I mentioned previously, we've been discussing alternate ways to handle stale documentation pull requests. Now this is a little more involved because we do have to take a look at the pull requests themselves, make sure that the information is either valuable or not, and then depending on what that result is, we can kind of address things from there. If the pull request is valuable, we wanna make sure that that's not lost. So Mark has gone through and put a handful of thawed labels on the older pull requests in the Jenkins.io repo. So here we have page one, there's nothing clear or there's nothing stalled there. But when we look at the second page and we go down to the older dates such as 2019, 2020, we can see the stalled label here applied. These are all really valuable and necessary pull requests. However, they haven't been worked on and they need more time and changes and edits made. So we do not wanna lose that, they are stalled. We've been discussing various ways to make sure that that doesn't get lost and is visible. So I was thinking something along the lines of maybe making them into an issue and linking back to the pull request or just copying the information over to provide that, these are very much in progress and needs and assistance from whoever would like to take a look at them. It's a great starting point for a lot of documentation and you can also see here that a lot of these are also Wiki migration pull requests. So again, this is information we've had. We need to verify that it's up to date incorrect for now but there's ways that we can do that without having to hold on to these older ones. Jenkins Core is using a stalled label just like that for their own pull request. So this is something that makes us a little bit more aligned and honestly just makes sense. So this is great to have and this is a good practice to continue on doing. If the request is not valuable, we'll just close it out. If there's been no action, no response from the contributor and something else that we're considering is proposed for close. That is a label that Jenkins Core uses. That would be for stuff that we're just not gonna approve except or stuff that becomes inactive. So again, a way to navigate those pull requests that maybe aren't worth it or that have been there for so long that maybe it's not correcting more because it's a little out of date. Those things can still be updated and changed and added but for the pull request itself we can consider a few different options. On the end of live notifications in Jenkins Core first of all, thank you to both Alex Brandes and Chris Stern who have been incredibly helpful as providing insight, opinions and just being a sounding board for this idea. This is something that we're really adamant about getting figured out, working on and applying. So the first thing is figuring out whether or not we can do this with the administrative monitor should be pretty straightforward and should be possible. No real issues there that I could see but we've been able to compile a really nice example of what the message can look like, what kind of information it can contain, what things it should be checking for and how it could be displayed. Mark, is there anything that you'd like to add in on this? Just, I'm being a very high level overview right now so if there's anything more detailed you'd like to share. Well, so the details that are there are a result of the conversations. There are still some gaps, there are some things that this couldn't do for us and we'll have to, I hope someone will have a bright idea as to how to allow it to do it for us or to do something, extension of it to do it. Right now for instance, when we end support for Java 11 someday in the future, let's say we're in October, we're in late 2024 and we're declaring the end of life for Java 11, that's not a file-based end of life. So we can't detect that we're running on Java 11 based on a file. It's easy to detect that we're on Java 11. Jenkins knows very well what Java version it's running but in the context of this concept of using an administrative monitor that's based on a file, it doesn't work here. And so I think this is valuable. I think it's useful and I'm gonna continue with it. It doesn't solve all the problems and so we'll hopefully find other ways to address additional cases. Great, awesome, thank you very much Mark. That helps clarify and explain a little bit and that makes absolute sense as to why it would not be able to necessarily determine the Java version in that case. So yeah, thank you. And again, this is something that will need a Java or a pull request or something to submit so that we can follow it and keep any feedback and or work done tied to it. So, to come. And then the last thing that I had on the agenda today was just discussing the intended early end of life for CentOS 7 for Jenkins. This is something that we've been discussing. There are lots of reasons to move forward with this end of life for CentOS 7, namely it's relying on a lot of older versions and just from the details here, it's missing things. It's just not the optimal way to go. There are several alternative options here. We have Alma Linux, Rocky Linux, REL, Oracle Linux. So in multiple versions with each, which is great by all means, check them all out, use what you feel comfortable with and what makes sense for you. The end of life is approaching. CentOS 7 has been in maintenance mode for, I want to say two years now, roughly three years almost. I think it was 2020. So it is not being supported anymore properly and we just want to make sure that this isn't an issue. So this will be a Jenkins enhancement proposal that will be created and again, will tie work to it and connect any suggestions, feedback or discussions to it for right now. There have been a couple updates already made in the documentation to utilize Alma and Rocky Linux over the CentOS 7 image. So it is being implemented just a matter of finding all those little corners that are fighting and updating them accordingly. And that comes to the end of our agenda today. Mark, did you have anything else that you'd like to share or any comments or anything like that? Nothing else from me. Thanks, Kevin. Okay, sounds good. Thank you very much. So then we'll call it there. Nice, smooth, quick today. Thank you very much. Recording will be available in 24 to 48 hours, maybe a little bit longer. Mark's got a lot of stuff going on this weekend. So lots of fun kids camps stuff and then yeah, all sorts of cool stuff. So it might be a little bit delayed, but it will be available. Until then, thank you very much for joining. Take care.