 Welcome to the Jenkins documentation office hours. Today is March 16th, and this is the EU, U.S. edition. Today we have myself and Mark Waite, and if anyone else joins, we'll be sure to add them and welcome them as we go. On the agenda today, we have some action items of blog posts that have been recently published. Just quick updates on the LTS release last week and our weekly releases. Documentation transition from Java 11 to Java 17. This is something we've been discussing for a few weeks and we'll revisit. Adding books to jengans.io, as this has become something that's popping up more and more now and we want to figure out alignment and standards for that. Improving end-of-life notifications and how we can better provide users with this information. How can we increase the visibility of this? How can we make sure that everything is seamless possible because it's hard sometimes and some things take people by surprise? There's the prep for CentOS 7 end-of-life which ties into the end-of-life notifications. This is something that we've been discussing for a bit now. And so potentially is gonna be removed from this sentence and we have moved Docs Office Hours an hour earlier in the day to account for the daily savings time in the US and more importantly, making sure that this is available and accessible for our compatriots and the new. This is, it's way later in the day than it needs to be and we want to keep that in mind to be respectful at our own time. Anything else on NeveMark or is there anything? No other topics. Those look like good topics. Okay, wonderful. And we have, okay. So we'll start with the action items. So two recent blog posts by Bruno Verrachtin both regarding the Minigen which is an awesome little controller machine. If you have not seen it yet or if you weren't at Fosom, definitely take the time to check these out. Bruno gives a background about what Minigen actually is and what it's capable of and has written another blog post about how it ties into Risk Me and other architecture and usage. He gives some background on how this came to be. It's just a really nice insight into what is possible with Jenkins and just the really out there uses that can come from it. And kudos to Bruno for putting all this together and making this. This is a lot of just kind of, I would say passion work at this point, but yeah, hi Bruno, welcome. Thank you. Thank you so much for the kind words. Of course. Sorry for being late. Ah, no worries at all, no. But yeah, these are really great blog posts and I think they do a really great job of just showcasing how unique and different each Jenkins usage can be and just the different ways that we can achieve the same goals. And thank you so much for the review and the suggestions and corrections on. That was much needed. Thank you. No worries at all. Always happy to help. The next post was just an update from Mark about our Alasian partnership and sponsorship. So we are gonna continue to have Jira available for Jenkins as Alasian is continuing to provide that for us. And so we will continue to have Jenkins Jira tracking. There was an update this past Saturday. That's now done of course. And everything should be working as it was before. Quick update. So the Jenkins awards voting period is officially open as of last Wednesday. The recent blog post here just shows what the awards, the Jenkins awards are and the nominees for them. You can use the Google form attached or LinkedIn the sheet here to vote. You do need a GitHub account but this is where you can go and make your voice heard. And I've also linked it here in the docs notes just so that if anyone is looking for it they can get to it very easily. And again, these voting will be open until March 28th and the winners will be announced at CDCon this year. So if you haven't yet, please by all means take a minute, check out the voting. And there are additional issues that show the awards and a little bit more information about them. So if you are curious, you can get some more info about that as well. And finally, we did publish our February newsletter last week. So this has now, this is now live on the blog highlighting a bunch of awesome things that we got to do in January, February, including FOSM 2023, which we have a separate blog post from our attendees and participants that show some insights and just some great reflection on FOSM, which was really exciting to be back in person this year. So thank you to everyone who attended and helped out with the Jenkins booth. Next up, just a quick update on the releases we've had recently. So last week we had LTS 2.38, 7.1 and we also had 2.375.4 and 2.394 coming up, 2.394 being the weekly, but the security team actually assisted in putting a lot of these together and putting them, putting together the change log and release notes for these releases. So a huge thanks to them for all their assistance with that. And yeah, this week we've also released 2.395 successfully and something that we noted, we have not seen any regressions for the new releases as of yet. So we're doing really well. This is great to see. Next up on the list here, we have the documentation transition from Java 11 to Java 17 at the point of Debian 12's release. Now I want to be clear, Debian 12's release is not going to include Java 11 but Java 17 instead. However, we're going to look to transition the documentation regardless of the Debian release to make sure that we're giving everyone the best baseline possible to work from providing the correct resources and instructions based on what seems to work best. Java 11 will still be supported. That's not getting dropped until 2024 at the very earliest. And the Java 17 is fully supported as of last August or September. I want to September. So there's no reason not to and it provides extra further functionalities and testing that just doesn't exist in Java 11. So it's a great time to make the change because of the Debian release, but the change is going to happen either way. It'll also be part of the Windows and Linux install docs because Java 17 will be the baseline we're using for that. I've emailed Tim Chacombe, so he's aware of the transition and on board with it. And one of the things that I just thought of was that we need to also make sure that any issues that are present in Java 17 are taken care of before we transition the docs so that if we do provide that instruction, no surprises. But this will happen sometime in April or May. So coming up soon, but we still have time to figure out what that's gonna look like. And again, adding books to jenkins.io is something that we've seen a lot more. So Kevin, actually before we go off that topic, there's a reminder. You said something there that was crucial and I learned of an issue yesterday that was specific to Java 17. And so you highlighted that we need to be sensitive to, we need to continue watching for Java 17 specific issues because they might persuade us to delay, upgrade of change of that documentation. Right now, I think the issue is resolved, but it was a particularly complicated issue that Basil Crow had to investigate that was specific to Java 17. He's investigated it. I don't know yet if the fix is released. But we've got to be continue monitoring bug reports to see if there are any that are specific to Java 17 that might cause us to say, oh, we need to delay this a little bit. Right now, I think we're on track April or May. We make that transition and announce it because people have still used Java 11. Right, of course. And Java 11, as we said, isn't gonna be dropped until 2024. So there's still lots of time left for Java 11 usage. Right. So Mark, was it in the Jenkins core? Of course it was. No, it was not. No, actually it was not. It was in the job DSL plugin. And so job DSL plugin, that's a rather obscure case, but it's got 40,000 plus installations. And so it's a very popular plugin. It's especially popular in very large installations, right? So there are companies that run huge Jenkins controllers and job DSL is very important for them. So they would have been blocked from going to Java 17 because this job DSL bug made it simply not work on Java 17. Maybe it's too early. Maybe it's not necessary, but do we have a Jira Epic or something in place somewhere in the documentation where we could list all the problems we have with JDK 17? We do. There's a, what Basel had created is a set of three phases for the Java 17 project. Just like he created a five phase, epics for each of those three phases. And yeah, there are epics for each of the five phases that we went through for Java 11. So we have an epic that we can attach there. It's a good suggestion. Let me put the... Yeah, thank you. But Basel being Basel, my question was stupid. Of course, Basel does that kind of thing. No, your question was not stupid at all. Your question was a very good question. It's just a delight to say, yes, that was considered and yes, we've got a way to do it. But I haven't checked to see if this job DSL bug is actually attached to the Java 17 Epic because that may have been missed. And if it was missed, it'd be a good thing to attach it. Thank you. Yeah, very good question. Thank you. Yeah, that's great to know. And thanks, Bruno, for bringing that up. I didn't think of it myself. So that's fantastic knowledge. Thank you, Vols. Okay. It's not stupid, cut it. I'll put the link to the bug report in. And let's see. So it was that a job DSL bug was specific to JDK 17 fixed by Basel in this thing. ER 1264, good. And so, and that's, there's an issue where was it that was, that has a Jenkins issue associated with it and we can link to that Jenkins issue and see if that Jenkins issue is correctly attached into the Epic. And it is, it's attached to Java 17 support, phase one support Java 17, good. But we should put that Epic because we don't know how bugs will arrive and not arrive. So when we announced this change through a blog post, for instance, we should probably put a link to that Epic so that people can see it saying, hey, look, we've switched. And here's the, here's the point of pride that shows you can go here if you think that there's something that doesn't support Java 17. And that's exactly like we had for Java 11 too, if anything. Right. Yeah. So whereas Java 11 had five phases, the Java 17 thing only has three phases. But yeah, it's the same exact deal. Fantastic. Thank you very much, Mark, for all the additional context. That helps a lot. And Bruno for a sparking conversation. Like I said, I had no idea if this was great. Anything else on that one, Mark? Bruno? That's for me. Thank you. That's it. Okay, thank you. So the next topic on the agenda is adding books to Jenkins.io. This is something that's been coming up a lot more recently. Folks are looking to contribute to Jenkins.io and adding a book is a pretty easy way to go about contributing. Right now, the books page looks like this. So we have just all the books laid out. The numbering in the list is gonna be removed pending my pull request. I've submitted a request to just get rid of the number order so that it's more general and not giving any sort of appearance of ranking. But what I've been seeing to is that with the books emissions, there's potential to update the layout or provide a little bit less or more succinct book summary here. Some of these can be a little bit longer, but the idea is that we wanna drive people to interact with that book itself, not give them the book on the page. So I was looking around and I did find this example. So OpenStack has a books resource page and it's really clean, really simple. It's just a cover image title, the author or publisher and then a really, really short summary of what the book's about. And then Link takes you either to the packed in these cases page for it or in other cases it can take you just right to the Amazon page. Let's see what that one's about doing in this one. Or this one takes you to the rescaler. So it's just a nice simple way to list the books and something like this I think would be a little more aligned with what we want for the books page. And then the how to add this, how to add a book entry is something that needs to be added to the Jenkins contributing guide. Once we've determined all of this and once we have decided that this is what we want it to look like, this is how long we should have the summaries be, et cetera. Once we have that we'll be putting that into the contributing guide so that it's available for everyone. Kevin, I finally had the time today to have a look at that. I was intrigued because I wanted to know more about what could I find in a book about Jenkins. So I think the first thing that's struck me that how am I supposed to go directly from the front page to this book page? I didn't find it. I had to use a search bar. It's a secret right now, Bruno. Oh, that's why. Okay, perfect, fine with me. Sorry, that's really embarrassing to say but it was an experiment launched to see how it would pan out and the experiment has turned into actually quite a useful thing, right? I think there's interest here but I don't think it's ready for prime time yet, particularly because of the numbers on the top left, the one, two, three, et cetera because they mistakenly lead people to think we've somehow ranked these or prioritized them. And I was almost ready to buy something but the thing is the latest one is not a subject I'd like to address as soon as possible. I would have been Jenkins to up and running if it wasn't from 2018, 2018, sorry because so much things have changed in Jenkins lately that I'd like something from last month. Well, and that hints that we may someday on this page want something that's sorts by published date or sorts by author or sorts by me, by publisher, right? Those are all valid questions and none of those things are represented on this page yet. Yes, but it's a project. Okay, I didn't get that earlier. Thank you. No worries. Thank you very much Bruno for bringing all that up. Yeah, and this was actually part of Hacktoberfest if I'm not mistaken initially and something that Chris Stern had originally pitched and followed through on. So, and this was around the time that Gavin Mogan was working on the web components for the header and footer. So I think, and this is just me speculating on what I can see from in front of me. I think it was just like a perfect timing of the book's page was created, but then the web, the components were created and they just didn't have each other. So we have the lovely components, the header and footer, but unfortunately it's not listed in the about link like it was intended to. So right now it's there, but you're right. It's not really readily available as a navigation point. So something we need to fix. But yeah, like Mark said, wanna make sure that everything is impartial and in line with how we wanna present the books. I wanna make sure that the formatting and text is okay. These number lists that are not formatted as a numbered list kind of take away from that. So there are a couple things that need to be adjusted, but yeah, this is something that I've noticed coming in a lot more of and with the amount of response people are providing for this, I think it would be very good to just have that kind of guidelines and the contributing guide too. And I think time or date of publication or the publication date and stuff like that is absolutely crucial when we're putting these books on the page because we do wanna make sure that it's relevant information up to date, nothing misinformed or perhaps referring to older versions that are simply not supported. So the books do need to be vetted a bit better. How we go about doing that is another question, but that's again something we can absolutely figure out as we go along. This isn't make or break to the Jenkins experience, thankfully, so we can take our time a little bit, but yeah, anything else on the books topic from Mark or Bruno? Nothing from me. Okay, thank you. Next up on the list is the improvement of end of life notifications and in tandem with that, the prep for the Cent07 end of life. So the way it's in right now is right now, when things reach end of life, we don't necessarily have a way to communicate that properly to our user base. We want to change that, of course, and make sure that users are notified if anything that they're using is gonna be hitting their end of life sooner than later. We have some examples right now. So for instance, Ubuntu 18.04 is one of those candidates. The blue ocean container page, the Cent07 container image, the Arch Linux agent container image. There are several things that we can consider coming up on end of life that these are things we want to notify people of and give them the best chance to take care of before it becomes end of life. We need to figure out how that limitation would be delivered and look and how it would give that information, but we do have this really nice site, endoflife.date that is, it's got an API guide, so it's open and interactable. So that could be something that is potentially automated down the line. It also has end of life for most things that you run into contact with while using Jenkins, including Jenkins itself. So lots of great info there, but utilizing that, leveraging that would be a good way to get this information out. We also are considering blog posts, other announcements within meetings, just multiple avenues to get this information out and deliver it to the user base. So, Kevin, you just reminded me there's something that needs to be fixed on the end of life.date page and I'm not sure how we explore that with them. You're right there, that's the perfect page. Notice that it shows 2.375, that's correct. And it is in fact a valid version, but 2.387 is not listed here. So we're missing the current LTS. Right. And I'm not even sure how to present it here because 375.4 is the current LTS, but we expect no further security fixes in it. So it's actually therefore, for their definition, end of life, the next one should be inserted. I'll insert it and see if we can get this right, but then I've got to have a conversation with the maintainers of this site to automate that release detection logic. I don't know how they do it. Okay, well, that's good. We caught that then. Make sure this is all up to date, because yeah, cause 2.387.1 also came out on the same day, but maybe the release order was just slightly different. Who knows? You know, I suspect that it's that their page is not correctly configured to automatically generate the next LTS version, and it may have to be a manual process. So this looks an awful lot like an ASCII.Doc page. I think it actually is ASCII.Doc, but it's a very simple to edit format, but the editing was required actual editing, not just a machine that ran a program. Got it. Okay, that makes way more sense. Good to know. Okay, great. Thank you very much, Mark. So, and in tandem with the notifications, CentOS 7 is nearing end of life next June. It's been a maintenance mode since 2020, however, and it is looking at older versions of Git and SSH. So two things that are crucial to plugins working and operating properly, that it just does not necessarily have. It's not supported by the Jenkins RPM installer and not maintained in its own container image at this point. The end of life is June, 2024. So again, like there's several reasons why pushing this to end of life now or sooner than later is the right call. This is something that Mark's been proposing and will be, if not, he's already created a JEP4. And so we're gonna capture the end of life in CentOS 7 and the Epic, announce the deprecation before it happens, making sure to stop running automated tests in CentOS 7 and just in general, making sure that we can remove all the CentOS 7 information from the documentation. This has started. There have been a few places where Rocky Alma 8.9 are suggested as opposed to CentOS 7 and there are a couple other options here. I forget what they are off the top of my head right now, but there are multiple alternatives that we can recommend instead of CentOS 7 or utilize instead of CentOS 7. And so making sure that the correct versions and up-to-date options are present in the documentations is one of the next big tasks as well. Mark, was there anything else on the CentOS 7 end of life information? No, I haven't submitted the Jenkins Enhance for proposal yet, but I will. It's coming. Okay, no worries, no issue there. Yeah, and the last thing on the agenda, again, we're just gonna move the docs off this hour as to an earlier time, one hour earlier, making sure that this is readily available for everyone in the EU, US. If we stick to crazy daylight savings time here on my East Coast, it's gonna be way too late and I don't feel comfortable with that for the whole rest of the world. So we're gonna adjust that and today's the first day, so yeah. So now it's gonna be at, it's gonna remain at one o'clock my time, EST, that's not UTC, yeah, Bruno, maybe you can help me one time. No, I don't think so, I'm as lost as you are. And yesterday I discovered that in Phoenix, Arizona, they don't change with summertime and wintertime. I didn't know that, which is kind of funny to me, and 10 days from now, it will be one hour later in France, so it will be about 7.30 p.m. So the time is fine with me for this week and even in two weeks from now, that's perfectly perfect. Thanks a lot for thinking of us European folks. Yeah, of course. Bruno, would it be better for you if we moved it even one hour earlier so it was right after Google Summer of Code office hours? Yes, but you need some time to eat. If it's 1 p.m., Kevin, I don't know. My schedule is so weird, don't go off my eating habits. My eating habits are not normal. Please don't worry about me. Oh, really? And back-to-back meetings is actually healthier for me than having an hour gap between them. Let me look for just a minute to see if it would work for me in the average case. So office hours for, okay, today, GSOC office hours. Okay, it would collide with advocacy and outreach if we moved it the hour earlier. Advocacy and outreach happens twice a week on Thursday, so I think it's probably better to just leave it at the current time. Okay, fine with me. As long as that's okay with you, Bruno. It is. If it's okay for you, Kevin, also, okay, perfect. Oh, yeah, I'm the one suggesting it. I definitely am okay with it. And I already made sure it doesn't conflict with anything from me as well, so yeah, we can just keep it at that time and just make life easier for everyone involved. Now that you have more of the time, I have to come every week. Tom! I mean, you don't have to, you're more than welcome to do what you need to do. Of course, no, no, it's a pleasure. It's a pleasure to be here and spend some quality time with you. That's cool. Oh, thank you, Bruno. I appreciate it and I'm glad you have fun here. That's nice. Thank you. Okay, done. Awesome. That takes care of everything on the agenda. I just realized we're over time by a couple of minutes, so we'll call things here. Again, thanks for joining. I appreciate it. The video will be available in 24 to 48 hours and take care and until next week. Thanks a lot. Bye-bye. Bye.