 Hello, and welcome to the Jenkins documentation office hours today is April 27, 2023, and it is the EU US edition. Today we have myself, Mark Waite, and Bruno Verrachton. And if anyone else comes in, we'll welcome them, as we always do, on the agenda today. I have an update for Google Summer of Code. The announcement is going to be coming next week, so just want to make sure everyone's aware. Recently, Alex Brandes has submitted a full request to potentially revise community feedback, so I wanted to discuss that here. LTS 2.387.3 is going to be coming out next Wednesday. The next LTS baseline is being discussed. There were some Java updates recently within the last couple of weeks for the various Java versions that we're using right now. So 11, 17, 20. CDCon is coming up, so just quick note on that. Reminder and some discussion around the plan to transition the documentation from using Java 11 to 17. Note for the success stories link that we now have, there is an update to XML handling for null characters, so that's something that we'll talk about and that's going to be coming up in weeklies and LTS eventually. One of the discussions we've been having is alternate ways to handle stale documentation pull requests. So we've made some headway and got some actions done there, so update from that. Mark's been getting a lot more information and data for the end of life notifications in Jenkins Core, so lots of great, great conversations and feedback happening. So we've got everything listed out here and we'll talk more about that. And then finally, as we've been discussing, the end of life for CentOS 7 in the Jenkins project. Anything else that we want to make sure is on the agenda today or anything else that anyone wants to know? No? That all right, thank you very much. So first things first, Google Summer Code is vastly approaching. Google is going to be announcing the accepted contributors on May 4th, so next Thursday. And then May 5th, we're going to have, the Jenkins project will have office hours dedicated to welcome those accepted applicants. So keep an eye out for that announcement. And we'll also have follow-up posts, tweets, LinkedIn posts about this. So even if you don't see it in one place, you're sure to see it somewhere. And just a nice welcome back to Yiming Gong, who is returning after being a contributor last year. This year, they're returning as they're coming back as a mentor. So really excited to have that return. And thanks for joining the project and the, all the, yeah, thanks for joining the project. The next thing on the agenda is this poll request that, like I had mentioned, Alexander Brandis has submitted about potentially revising community feedback. Now this is specifically feedback for the changelog. So right now, there is a straightforward way for people to say they're either having a great time with the release, having a time, and having a horrible time. So they're very simple measurements. It's just numbers and kind of a status. They do give the option to provide a JIRA ID when someone clicks on it. But Alex had pointed out a lot of things that doesn't necessarily always happen. It's hard to action on those things. If there's no trail or person or contact, it's not necessarily beneficial to the developers and people working on this as it's harder to really, really pin down what's going on and what's happening. And so we've been discussing this a little bit further. And I think it's worth examining this and taking a look at. But I think personally that there's ways we can use these to our advantage as opposed to potentially just having them be a counter, essentially. So I've questioned whether or not we could actually use these as a means to get someone into the creating a ticket window. Or if they're saying they have to roll back, I was thinking maybe we could have it redirect to the JIRA issue tracker where they could create the ticket instead of asking them to provide the JIRA ID number, recognizing that that could end up in a lot of unnecessary tickets. And I don't want to overload anyone's system in that sort of regard. But that might having more information in this case might be OK because if it's all related to the same issue or if multiple people are reporting the same thing, they can all be linked together and potentially have those extra ones closed out in favor of one. But again, that's a very different view. And yeah, I'm not sure what the final result will be, but I'm just wondering if there's ways to use these to our advantage as opposed to just removing them outright, for instance. Yeah. And my preference is not to remove them. There have been a number of discussions about ways to improve them, but nobody willing to do the implementation work to implement the improvements. And I'm hesitant to lose the data that we're gathering right now to not have that in the future. We don't have anyone who's committed to do a replacement for these, right? The rating system, if you scroll down a little bit, Kevin, you'll see, for instance, sometimes there's Jenkins-420 that's submitted or Jenkins-1. And the bug IDs are, here we go, on 375.1 you see Jenkins-2 and Jenkins-3 and 299, which are, in fact, not valid or useful bug reports. The complexity there is that we just don't know in the context of this page if what they're submitting is a useful reference or not, saying, oh, it's a closed bug report actually doesn't help it. Because if it's a closed bug report, but it really caused them to roll back, that's a valid thing. If it's a non-existing bug report, okay, that might be, but it's easy to choose novel numbers that are existing bug reports that are irrelevant. Two, three, those are probably real bugs, but they didn't actually affect 2.375.1 in any way. Right. And more than likely they'd been closed for some time if it's going to be one or two, something like that. Absolutely. Since I know we're up to 70 something thousand, but yeah, but yeah, and I definitely don't want to take that stuff away as a matter of what could come across as seeming less transparency or just less insight. I think it's, even if it's not the most valuable thing, it's nice to have just so people can take a cursory look while they're going through the change log to see, oh, some other people are having issues. I should be careful or look out for it. It might just be enough to signal that in someone's head, so. Great. Yeah, Bruno, any opinion from you? No, I only discovered these weather icons a few months ago. I don't know. I think they are quite useful at they are, and you're right. Giving more freedom to the end user to declare new Jenkins JIRA issues or referring to non-existing bugs doesn't really make sense. I don't know how we should omit that, but I'll keep an eye on your discussion. Kevin, Mark, Alexander and so on, because maybe something good will come from that discussion. It's good as it is. It could be better, but I have no idea how better could be implemented. Thanks for asking. So Kevin, if you open the weekly, we can see on already on page one above the fold, we can see to an example of a very useful use. And last week, so you see under 2.402, 7.1156 is actually a very important. Oh, we've got a regression there and that that one really matters. I understand why they rolled back given this description. So so this one very, very good. Now, if you go back to the page, you'll see the release prior had three reports of rollback and at least one of them said Jenkins dash one, which is nonsense. But how can we screen between nonsense? No, we can't. OK, I think I think you said it exactly. We can't. We there isn't there is other than the human screening that we do right now. And and given that the human beings who look at this are looking at it for answers to the question, shall we consider this as an LTS baseline? And I confess, I use that in my prepping an email that says, I think we should use 2.401 as LTS baseline. That email was inspired by the fact that, hey, there weren't any credible reported rollbacks for 2.401. Yeah, makes sense. Yeah, just looking at it from that level, makes total sense, Mark. Yeah. And and all I if if it hasn't resolved itself, I plan to discuss it further with Alex Brandus at CDCon May 8th and 9th, because he and I will both be in Vancouver. And Gavin Mogan, if he if he's there is also one who's been involved in the discussion about ratings. Mm hmm. So you don't have to be logged in or whatever to click on that. Anybody is free to click. Yeah, so even a boss could, yeah, whatever. Yeah, exactly. Thank you, Mark and Bruno for sharing. Appreciate it. I'm glad we're having this conversation and I will continue. So yeah, anything else before I move on from here? Is that OK? Cool. So next thing up. So we have our next LTS release is coming on May 3rd. It will be 2.387.3. So the RC, the RC candidate, everything's ready to go. Testing is available. Change log and upgrade guide are been added and submitted. All we're waiting for is the approval, the final approval and merge on that. And we'll be good to go. And then as Mark had shared, we have also started the discussion for the next LTS baseline. Right now, the highest voted suggestion is 2.401. As Mark said, there were no real credible threats of rollback or anything that was reported, so it seems like a good baseline to work from. And yeah, it does have support from others as well. So if you have any strong feelings one way or the other, please check in on the mailing list and share. Next up, there were recently some updates for various Java versions from Timurin, OpenJDK and Oracle. We've put the Timurin ones here as they're the most reliable and most used in as far as Jenkins goes. And just they have 11.0.19. This is that latest release, the 19th. It's got notes and there are. Yeah, this is something that everyone should just be aware of and make sure they're doing. Mark, is there anything specific for the update or why people need to be aware of the update? So there were security fixes in each of those. I'm not aware of anything that specifically motivates you. You absolutely must upgrade immediately, but upgrading to get security fixes is a good thing. OK, perfect. So it's just a recommendation for our users. If they want to, they can upgrade to those versions, but there is nothing yet in the documentation indicating that people should use Timurin and these versions of Timurin, am I right? Well, actually, the documentation does describe that the Jenkins project prefers Timurin. Now, OK, it's a few months ago. My my understanding, I think that pull request has merged. It's worth checking just to be sure. But but there was a there was an addition which was trying to describe to people that the Jenkins project prefers Timurin. And and, of course, our container images are using these latest versions already, right? So shortly after the versions were, oh, I think they are. Now I I'm not so sure. Yeah, I think I saw the PR for the 11.0.18, but don't know about the 19. Yeah, let me check because I need to check to see if they if Timurin has updated the Yeah, as updated their image for us. Good question. And my next question, which is linked, is is there some part of automation in the documentation website to reflect the new versions of the Timurin bills? Thankfully, not needed because we don't refer to specific version numbers of the Timurin bills. So so we and we like that. OK, so Eclipse has issued 11.0.0.19 container images. For yes, so so it's possible now for us to do the upgrade. It wasn't a relatively few days ago, so we're going to need a pull request to our Docker containers. Great, thank you about that. Thanks very much, Bruno. Thanks, Mark. Next up, so CVCon is approaching. It's going to be May 8th and 9th. That's where the Jenkins awards will be provided to the winners and among the other CDF awards that will be presented there. So if you haven't already signed up or registered, there's I think there's still time to do so and get over there. So if you're going to be there, come by, stop, say, hey, Mark's going to be there, as he said. Alex Brandes will be there. Gavin Mogan will be close enough that he might show up. But otherwise, people will be there to represent Jenkins and share and talk. So by all means, come on over. There's also going to be a handful of sessions regarding CDCI and Jenkins. So we have a recent blog post that just outlines a couple of those providing some information. So one from Fidelity, one from one regarding Jenkins and other releases. So there and Mark's getting well, Mark's going to be participating in two sessions. So really exciting to have that. So thank you, Mark, for representing next up. So right now we've been talking and discussing the transition for the documentation to move from Java 11 to Java 17 for things like installation instructions and other hardware software requirements. We're not dropping Java 11. We're just transitioning to Java 17. It's got a longer life right now, has more functionality, faster testing and just provides overall better development resources for anyone using it. So I've created a GitHub issue that is that contains the various pages that I found where this transition should be looked at and potentially happen. It's mostly, like I said, mostly installation. The Java upgrade instructions also need to be changed because right now it's talking about the move from Java 8 to 11. So that will have to be updated as well. But this is a result of the Debian 12 release that's approaching. Not sure exactly when that will happen, but it will not be delivered with Java JDK 11. So this is in advance of having to worry about that across the board. We can get ahead of it and we can start using 17 as a recommended option. We may hopefully get people to migrate over sooner than later and that way have less to worry about when it does come time for end of life for Java 11. We're not dropping Java 11 support at all. It's Java 17 is also available for full functionality and we want to get people on that. So more to come on that once I start getting into the transition. We'll provide more updates here. One of the other things that I wanted to note is that we recently have the success stories in the stories site as a navigation link now in the top nav bar here on Jenkins.io. So thanks to Gavin Mogan and Alex Prenis for getting that set up and working. So now we have this really nice success stories link at the top of every Jenkins page so that the stories page is highlighted and available. That's cool. What is a process for a user to post a success story? So as far as I can recall, there was a Google form originally but now it's submitting a pull request. OK. And there is a stories repository specifically for those pull requests. Got it. So Kevin, I think if you go back to the top level page. Yeah, we should be able to see. Oh, maybe not. OK, so I thought there was a there was a link there that gave us obviously not that told us where to find how to submit a new story. So click read user stories. Yes, there it is. Submit a pull request about your goals and challenges. There it is. Yep. Yeah, and I think I think if anything, it just needs to be updated to have like a link to the correct repository to submit the pull request so I can take care of that problem. Well, or scroll to the bottom of the page and let's see if it's got an improved this page link. Nope. OK, yes. So then that that should be a hyperlink. OK, cool. I'll go ahead and I'll submit a pull request for that after our office hours is over. Thank you. Great. Next thing on the agenda that I wanted to bring to everyone with attention is that there was a recent update for how XML is handled in Jenkins. Specifically with the use of the JUnit plugin. So as it was before, ASCII null characters could be both written and read fully without any issue. The recent change from the KXML2 driver to standard sex driver has made it so that while the null can be written, it cannot be read. So if this is something that you run into or are experiencing, you do need to update to the newest version of the JUnit plugin. It was just pushed a couple days ago or in within the last week, regardless. So this is a very, very recent change. It's going to be part of weeklies going forward. It did not make it into the 2.387.3 LTS. So it will not be part of that, but this will be in effect going forward. So it is best to update everything now and take care of it. So there are just so everybody's clear. Null is illegal in XML 1.1 as a data value. It's simply illegal. So we were writing illegal data and reading illegal data. And now we've we've switched with the upgrade of this reader so that we will we will we now have the ability to write but not read. And now it's with the change to the JUnit plugin, which was the one thing we knew of that was writing null bytes. It no longer writes nulls. So will there be a period of transition when people will get some errors because of the read of the null and then they will modify their dependencies and then it will not be a problem anymore. Yeah, so if you're running if you were running a Jenkins weekly or prior to this prior to the core change, which is 2.402 and earlier or a Jenkins LTS and you're running an older version of the JUnit plugin, it will it will give you if I remember, it gives you an error message that says, hey, I can't read this file. OK, but if you have a recent version of Jenkins and the list of plugins updated, you won't face this. Correct, correct. So by by current version plus current Jenkins core plus current JUnit plugin, you will not see an issue. So I won't see that. Right, thank you. Exactly. It's only if you're running an outdated, outdated version that you could see it. Thank you, Mark, for adding in the context there. And there are actually both a GitHub issue and JIRA issue for this. So I'll be sure to add those into the document agenda just to make sure that those are available for for contacts and historical purposes. Next step. So we have five minutes or so left. I want to be conscious of everyone's time. So we've been discussing alternate ways to handle stale documentation pull requests in Jenkins.io. So we've been discussing if it's stale and not valuable. We close it. If it is valuable, however, we want to make sure that that information and that work is not lost. So alternative ways to make sure that that gets kept as it is and can get additional eyes on it for anyone that might want to work on it or continue adding and fixing and updating. Some of the some of the pull requests require a little bit of more knowledge and more expertise in some areas. So it may be tough, but there is a great base to work from in all of these. And Meg Whitestone or no, sorry, I can't remember Meg's last name right now. Meg McRoberts. Meg McRoberts, yeah, has done an excellent job and there's a bunch of pull requests that update a lot of the documentation that just have gotten stalled because they need some further additions, corrections, updates and stuff. So there's a lot of great stuff there that we can just take on and work from. So we do have a stalled label that has been applied to these pull requests as well. So for anything older, it's marked stalled. We have that, we're just waiting to do the next step of what do we do with that? Putting it installed is good for now, but ultimately we're gonna need to make sure that it's available for other people. And if it's a good first issue, we can do that. If we put it in the issue tracker that at least opens it up for other people to work on. There's a lot of ways to go about that. Something that we also talked about with Alex Brandes is that the Jenkins Core repository has a proposed for closed label. So that's used for pull requests they won't accept or they have an inactive submitter that are not responding or updating. So again, something similar we could use that we could implement and use that in Jenkins.io repository, no problem. And it would give us something else to at least signify and notice on the pull request page. Bruno, Mark, are there any other ideas or suggestions about how we could potentially preserve those a little and make them more visual? Actually, I think we take that as our plan and just agree that we think that's what we're gonna do. Okay, that works. The only problem I see with that is that if ever a submitter of a pull request removed the branch from his fork, we will lose the information nonetheless if I'm not mistaken. If you create a PR then you remove your branch, the information you wanted to incorporate into the main branch just disappears. I thought that it was retained in the pull request. I may be wrong. I thought it was. But nonetheless, because if I recall correctly, even if I believe it survives, even if they delete their fork. Okay, cool. But it's easy to check. Good idea that we may want to check it. Yeah, definitely. Thanks, Bruno. Appreciate that and thought of that. Next up, so end of life notifications in Jenkins Core. This is something that we had been discussing. The idea is that it can be delivered via the administrative monitor or administrative monitor. And right now it's designed as a general solution to communicate end of life dates. There are gonna be factors, attributes that we wanna account for and look at to use for when this message can be sent out, who it's gonna be sent out to, what that end of life version is, et cetera, et cetera. So as I mentioned, Mark's been getting more and more insight and feedback on this and various things that we can use as criteria. The most recent one is the start date for end of life messages, which essentially would just be when do we wanna start sending these out to people? And not right now, but in a specific, like a given timeframe, six months before the end of life, so that there is ample time to see that notification and actually act on it instead of having it be so sudden that if there's no time or too far away that it gets lost. And this also will allow us to end of life container images. So in not only just the platform systems versions that people are working on, but full container images as well so that we just clean things up, you keep things nice and streamlined and people are using the up-to-date versions of Jenkins and anything else that we're working with. And then finally, so the early end of CENTOS 7 for the Jenkins project has been discussed in the docs office hours for a little bit now. Mark's gonna submit a JP for that and we'll work from there to get the end of life straightened out on CENTOS 7. It's approaching sooner than later. It's no longer being supported by the developer and we do have alternate options available and even listed in the documentation such as AMA Linux 8 or 9, Rocky Linux, REL, Oracle Linux, and there are others. So there is still more to come on that but the work is being done and we're getting everything ready to go for that. So, okay, so that brings us to the end of our session. Did anyone have anything else to add, note, comment, share? All right, in that case, I'm gonna go ahead and stop the recording in just a moment. Recording will be available in 24 to 48 hours and thanks again as always for joining here today. Take care.