 Welcome to the Jenkins documentation office hours. Today is May 11th, 2023, and this is the EU-US edition. Today we have myself, Mark, Wade, and Bernadette Rockman. Thanks for joining, and we'll welcome others as they come in. On the agenda, I have the April newsletter, which we just published yesterday. The Pipeline Step Reference had an issue just this past week. We've got some temporary fix involved, but we'll discuss that a little bit more. Google Summer of Code is officially now underway with the projects and contributors being announced, so we'll talk about that. We can discuss the community feedback suggestions that Alex Brandes has provided in a pull request. There's the documentation transition from Java 11 to Java 17, end-of-life notifications in Jenkins Core, which is something that we've been discussing and going back and forth on what that might look like and what we can do for that. The early end-of-life for CentOS 7 in Jenkins, again, something that we've been discussing for a bit now, and a newer topic is improving developer documentation so that we can remove the work-and-progress flags. There's a handful of those pages. I've actually created a list of them, and we'll go over that. Anything else to add to the agenda here or is that looking good for everyone so far? Nothing else from me. Okay. Cool. First things first, again, so we just published our April newsletter yesterday. This is live. It has everything that we've accomplished over the month of April, some really nice insight, and just a big shout-out and thanks to DigitalOcean. We mentioned it a couple of times throughout the newsletter, but they did provide us with an additional credit to help us get through some higher usage times, so we're very, very thankful for that. There are other notes, and there is a brief recap of what Jenkins.CDEcon, since it just finished up, we will have more information about this later on, and Alyssa, Tom, who contributed the Outreach and Advocacy part, noted that the CDF YouTube channel will actually have recordings in about two weeks or so, so keep an eye out for more there, and we'll actually have a blog post to announce the CDF Award, or the Jenkins Awards winners that were also presented at CDEcon. Highlighting Daniel Beck, Jan Faracheck, and Mark, do you remember who won the Security Award? Top of your head, I forget. That was it. Daniel Beck was security, Jan Faracheck was most valuable contributor, and I got the Advocate Award. That's right. It was you. You won. Yeah, so a lot of great times, and there will be more insights in everything from CDEcon, GetOpscon, and the coming weeks from various outlets. So last week, there was an issue where the Pipeline Steps page was not showing nested options for some of the various steps and strings. We did some backtracking and testing and found where the issue looks to have been created. Mark's created a temporary fix. So right now, if you were to go, if we go to the steps reference guide, it does display properly now. So it has been fixed in the meantime. There still needs to be some testing done and some understanding of what might've happened there. But this nested choice of objects list was not showing up whatsoever. Again, the temporary fix has solved that for the time being. The nested objects are all being listed throughout the guide. So we're good with that for the time being, but again, there is an issue in GitHub for this. There's more testing and work that can be done. Then you can follow the additional information and work there. Yeah, so really pleased actually to share that Vihan Thora, the author of the Pipeline Steps doc generator, most recent changes. So Vihan was a Google Summer of Code contributor last year in 2022. And that project was what created that nice work on that much better checkout page. Vihan did an investigation himself and was able to duplicate the problem on his own development environment. His workload right now is heavy and so he's not able to do much more than that. But I've left it open that there is an automated test now that will reject or block any pull request that would cause the bug to reappear, to the bug to again become visible. So the automated test is flawed and imperfect and sort of horrible in that it checks to see if a particular file is at least 75 kilobytes long. But that's good enough, it detects the problem. Yeah, and I don't know that Vihan will ever be able to submit a full fix. What Vihan said was, hey, I'm heavily loaded at work right now. And I replied, we'll leave the issue open. And if he or I or someone else is able to work on it, great. For right now, we have the benefit that the documentation won't be broken. The negative is it means that we're stuck one version of parent POM behind the current parent POM version for Jenkins Core. And that's okay. Yeah, one version behind. Yeah, exactly. And what it probably needs is someone who's willing to go in and investigate fairly deep details about why is this thing failing in this way now? It's not at all clear to me what's going on that's causing the failure, but I did a very high level investigation, right? My investigation was find the change that causes the problem and write a test that will tell me if the problem is visible or not. That's it for me. Great. Thank you very much, Mark. I appreciate the additional insight and information on this. And yeah, and thanks to Veehan for first of all creating the steps, docs in the first place that is incredible and night and day difference from before. But yeah, this is something that we can definitely step in and help out with and investigate if we can. So, great. Next up, the Google Summer of Code has officially announced its accepted projects and contributors. So we did have a blog post to announce this and share this that was published just last week. But just really thankful for all of the participants, candidates, applicants, the work that has been done already is outstanding. We had a record like way higher than average number of proposal submissions in and of itself, giving all of the lead mentors and org admins a lot more work to do, but they got it done huge thanks to Alyssa, John Mark, Bruno, and Chris Stern for taking care of this and leading us on this. It's been fantastic and we couldn't do any of it without you. Yeah, just congrats to all the selected participants and contributors. We're really excited about what's to come and we hope you get as much out of the Google Summer of Code as you possibly can. The four projects that were accepted are the Alternative Build Tools for Jenkins.io, the GitLab Plugin Modernization, Jocker for QuickStart, and the Plugin Health Scores Probe Projects. So just continuing the work that we've been getting done and looking to move Jenkins.io and Jenkins in general to the next level. So really, really excited. Yeah, all the projects are medium complexity, so shouldn't be anything that we can't finish or at least get to a really good point with by the time the end of September rolls around. Next up, so there was a pull request that Alex Brandes had submitted recently suggesting possible revisions to the community feedback. Specifically, this refers to the change log options for users to respond. There are pros and cons to this. There's things that could be improved for sure, but at this point in time, it's tough to say what would be a better option. This does provide some insight that is useful. And at the very least, even if it's not the most intuitive thing for a user to use or if there isn't a way to prevent things like Jenkins-1 from coming through, there is still some value there. It would obviously make life a lot easier if we could go and track these submissions back to the original creator or submitter so that we could talk with them and discuss further what kind of issues they're facing and what kind of troubleshooting could be performed. But removing it entirely is a little drastic in the sense of, for me at least, we're allowing transparency, we're at least giving that kind of litmus test sort of overview to remain so people can just make a decision based on, okay, a lot of people are not having any issues or maybe there are some issues here that I would like to prevent from happening. So even if it's just a cursory piece of information, it's still something to go off of. Mark, Bruno, did you have, I know that Mark you've commented and suggested in the issue, but any other thoughts or suggestions? I'm a little bit, feel a little bit sheepish, a little bit ashamed to admit that I didn't discuss it with Alex Brandis when he and I were having dinner at CD-Con two different nights. The topic didn't even come up. We were having many other good conversations, but not that one. You don't have to feel ashamed. Of course, I would have done the same thing, sharing a nice dinner with a nice person. Of course. No, I was wondering, there was no incentive to report everything goes well. So why do people click onto Sun icon? I feel grateful for that because most of the time people just say when everything is going wrong, not when it's going right. So it works, I don't know why. And your observation is, and the data supports that. We see, I see for instance that 90,000 to as many as 100,000 users upgrade to the most recent version within four weeks of its release on the LTS. So this is the page that Kevin shows when I look at the distribution of versions adopting the Git plugin. So one example, right? I see that there are from 80,000 to up to 100,000 that regularly adopt the most recent release. And yet with 80,000 controllers, 70 positive votes or 140 or 190, obviously there's not much incentive for people to report their results. And we're okay with that, right? It's, it's, it does no harm for them. We don't, we don't, I don't think we want to put any more active mechanisms to encourage people to come click these because it's okay the data we're getting. Okay, and Kevin, you asked for thoughts. So let me give you some things. I'm not really proud of it, but I'm not so good at math. So what if we had some percentage written, you know, because I know three is nothing compared to 69, for example, but just as percentage could help me understanding what's going on. And could we have some kind of graphics, you know, showing the progression along the time of the number of, yes, it's doing okay. No, it's not doing, it doesn't make sense. I know it was just an idea, you know, graphic of the third, showing the progression. But yeah, it, it's not meaningful as of course the code is static. So the progression in time doesn't mean anything as a code doesn't change. So forget it, it was just a junk idea. Well, but, but I think, I think you've got, at least to me it sounds like an interesting concept. When you think about what, how might we graph that data and we can graph the data, right? We could have a separate indicator which says how many people gave a rating? How many, how many times people is the wrong number? How many times was the ratings icon clicked? Because that's literally what it's measuring, right? So rating icon clicks and, and saying, hey, that, that may already help us see something. And then fraction of those that were rollbacks also could be interesting. Yeah. And I, I, something I thought of, Mark, when you mentioned that you notice it's like a four week span of adoption, it would be interesting to see what those numbers are like right when the new LTS drops and like it's gradually like graphing it like Bruno saying and seeing, you know, first week there's X amount of clicks, but the second week there's this many more clicks and then third week it maybe drops down a bit, but then the fourth week everyone's to a point where they're like, okay, this is fine. Next LTS is coming out, I can upgrade. So it would be, it would be interesting to see like the trend of when most people are actually like clicking on that or something. Yeah. Yep. So, yeah, no, all great ideas. Thank you very much. Po requests are welcomed. I knew it was about to come. Yeah. And you could predict that the generation of most conversations, right? Po requests, welcome. Of course. Great. Okay, perfect. Thank you very much Mark. And thank you Bruno for sharing your thoughts. I like, I like really enjoyed the idea of having a graph to at least share some more insight into what's going on. Next up on the agenda. So we've been discussing and talking about the documentation transition from Java 11 to Java 17. This was originally spurred by the upcoming release of Debian 12, which will not ship with JDK 11. So we decided that the Jenkins documentation for installation for Java requirements, stuff like that will transition it to using Java 17 as the preferred option so that we can get that transition happening now and encourage people to use the top of the line. 17 provides better testing, faster testing, more edge testing, just develop, development environment overall is better. So there's no reason not to use Java 17, but if we don't start using it now, people may be more reluctant to try it on their own. So this would at least give them the indication that Jenkins endorses using Java 17 in the project. And that's what we wanna do. So yeah, there's a GitHub issue for this that I've created that goes through and explains this a bit further. It also highlights some pages where this information would need to be updated. I started working on this myself and have gotten to a couple of places where I'm okay with the information. I have run into a couple of struggles of just trying to make sure that I'm getting the steps exactly correct and make sure that I can go down to the root level, but it's still being worked on. It's still something that we need to do and we'll be working on. So even though the W-12 release date is looking at June 2020 for you right now, we're hoping to have that finished before that happens. Plugins do not need to require Java 17, but we are saying that plugins should test with both. The tutorial does guide them to test with both, describe tests with both Java 17 and Java 11. So the plugins and other documentation should reflect that. There is no open pull request yet for this. I have been working on things locally and we'll be submitting a draft pull request at the very least to get that into GitHub and make sure that it's available for others to check out, comment or review, suggest and potentially assist with in getting some of the information corrected or some of the steps properly squared away. There's also a section in the current upgrading Java guidelines that discusses the Oracle JDK 11 licensing and how it's not available to be listed. At this time, the Oracle JDK 17 may not fall under the same limitation. So I'm doing a little bit of investigation to find out whether or not that's a more open policy and it can be used. If not, we'll make sure that's clear as well. Is there anything else on the Java 17 transition mark that you wanted to make sure we discuss or put in the notes here? Nope, those are the topics I'm aware of. Okay, thank you. So the end of life notifications in Jenkins Core is something that again, we've been discussing. Mark's been able to talk with some other contributors and such as Chris Stern, as Alex Brandes to get some feedback and suggestions on how those could be handled and where. Mark has submitted a pull request, a draft pull request to add the monitors. However, there was some suggestions and feedback saying that it might be a little much or if something can be done to make things easier for the process involved. So it just needs some rework. Mark will be taking care of that and handling things and we'll be able to share more info when it's available. But we are getting somewhere with that and that's the important thing. And we do have the means of providing an end of life notification. It's just a matter of how it actually is done. Oh, yep. Once that's merged, we will have. And I've got a major rework to do on that pull request. It was a good first experiment and it's good to throw the first experiment away. So I got some good feedback and the feedback will make the final implementation much better. Great, good to know. Thank you very much, Mark. And as noted, not available, not an option just yet, but when it comes, it will be made aware. The early end of CENTOS 7 for the Jenkins project has been discussed at length for some time. And I think we're at the point where now, Mark of JEP is just gonna be submitted for that and we'll be going from there with it or is there? Yeah, I think I may even, so it's been awfully quiet in my request to the Jenkins developers list. I submitted a message to the Jenkins developers list saying, I'm proposing this and no responses that were negative to it Basil Crow observed, hey, we've already dropped support and other projects have already dropped support in various subsections. For instance, the container image on which we base our agent images, our CENTOS 7 agent images and our CENTOS 7 controller image has been unmaintained since 2020. So it's not that we're somehow doing something breathtakingly different. There are many places where CENTOS 7 support and Red Hat Enterprise Linux 7 support is going away. Great. Yeah, I did see Basil's message about where other projects have dropped that support as well. So yeah, I think it's good that we have the actual experiences and anecdotal evidence to say, hey, we're not the only ones. This is pretty common. So yeah, great. And then the last topic I had on the agenda is improving the developer documentation so that we can remove the work in progress flags. So this is definitely something that can be handled by various people. This isn't one person job by any means. What I've done to help is create a list of the work in progress pages. So I've got the directory and then the pages and what I think their prioritization should be. The stars are just one through five, five being the most urgent, one being not. But things like managing users, managing tools, obviously securing Jenkins, these are important topics, but they also require that knowledge and that expertise that know how of what these changes should be, what the content should be updated to or what should be included. So it is not something to take lightly. It's not necessarily, it's definitely not a good first issue type of thing. So for the developer architecture, there are a few pages where there's just nothing available on the page, so it does need content or we need to figure out whether or not that's gonna be a valuable section to include. I think there was, yeah, these two system administration pages that I found with Chef and with Puppet, there is no content. I haven't honestly heard anything about either of these in some time. So I don't know, for instance, how relevant those would be if it's worth keeping those pages, if we should look at other options, maybe there's a different tool to do the administration with. So yeah, there's just some ideas again and I've put some notes on things that they, where they do have some content and might just need further information or expertise. So yeah, just there's a little good amount of stuff but I noticed that there's also probably 40% of the pages do have content and it's more a, it seems like it's not finished then there's nothing there. And then one of the other, a couple of other things that I noticed. So with the recent update for the XML values, not reading null, backward compatibility I think might need to be updated for that. I'm not 100% sure, but that's when I was reading that seemed to come up. The developer navigation itself is unordered in any seeming way. So I submitted a pull request earlier today just to reorder them in alphabetical order. I'm not saying that this has to be the way but going from this to this just feels a little bit cleaner and nicer to read. I would also be open to putting these in order that makes sense workflow wise for the developer. Like if we wanna start with initialization or just building and debugging something very straightforward and then releasing plugins and stuff can go or publishing plugins could go down here. If there is a workflow order that would make more sense for a user going through this documentation, I'm 100% open to it and happy to change things accordingly. I just figured that we could, this would be a quick low hanging fruit, something easy that we could just make the navigation and topics a little easier to navigate. So any thoughts, questions, concerns on the developer documentation stuff, Mark or Bruno? Okay, cool. So then that covers everything I had for the agenda today. If that's taken care of. So the recording will be available in 24 to 48 hours. And yeah, we'll see you next week. Thank you very much for coming. Appreciate it and take care. Bye now.