 Hello, and welcome to the Jenkins documentation office hours. Today is October 19th, and this is the EU-US edition. Today we have myself and Bruno Verrockten. Mark's not here today. He's at DevOps World Tour giving his fantastic talk along with all the other participants and speakers. So we'll be sure to get some insights into everything next week when Mark's back. But for today, we'll go over the agenda and take things from there. On the agenda, so we've got Google Summer Code. It's completed just in quick updates. We've been discussing this previously, so we won't spend too much time on that. The prototype JS removal from Jenkins, which appeared in one of the most recent weeklies, and how that's going to be affecting the LTS is going forward. Hacktoberfest 2023 stats since we've had a week now, we've got new numbers to report there. The documentation update for the Debian packaging site. So that's pertaining to a poor quest that we've discussed recently in Docs Office Hours as of a couple of weeks ago, I want to say. But just something small that we made those changes. The Jenkins Governance Board and Officer Elections are going on now. So just a quick update on that. Chamber Newsletter was published. We have the Java 11, 17, and 21 discussion and an actual Jenkins enhancement proposal to look at nowadays. Great. The update CLI discussion that we've started last week, the process of choosing a plug-in bomb, which have not had any progress since then. So we're going to remove this for the time being. Then housekeeping, so Docs Office Hours Asia is canceled for today since Mark's at DevOps World. There was talk about next week, I can't remember if that is certain. Neither. Yeah. Well, but we can figure that out in due time. Anything else on the agenda for the agenda? No, that's okay. Thank you. Okay. Great. So Google Summer Code, so we've discussed this previously. Google Summer Code has completed now, all four projects were completed successfully. There's still some additional work to deploy these projects, but they've completed and again, we appreciate all the work that every single participant put in for this. Really fantastic. As far as the version documentation for Jenkins.io, Chris has been working on that with Fadit. Chris has started the conversation with the M4 team to figure out what we need to do next for deployment and preparation to get that ready to go. There are some notes that we've put down here about some of those steps and we do have the demo site that Chris has. So the version documentation for Jenkins.io, I believe this link. No, it's this one, the prototype site that makes more sense. But yeah, so really nice, really great. It's got 2.401.3, so it's a little behind, but that's okay. This is just mock up. So yeah, looking really good, really excited to see that and in due time, we'll have some more information when they are ready to be launched. We discussed this. Sorry, Bruno, do you have something? Or is that just? Thanks for asking, Kevin. But no, I haven't been able to progress on my project with Ashutosh in order to host it within the Jenkins.io or Infra organization. So it was okay not to talk about that. Okay, great. Sorry, I think I just heard something on your side and thought you was wanting to speak up and I didn't want to interrupt you. Sorry. No, no, no, thank you. Cool, moving on. Prototype has been removed from Jenkins as of the weekly 2.426. So this is a concerted effort by a ton of contributors, especially thanks to Basel for writing the blog post and getting the ball rolling on this. He's written this up to explain the process and he had a previous blog post that was published back in May, explaining the why and how behind this process. So thanks to him and all of the contributors that helped with this removal. Again, none of this is possible without the help of the community. And this will be implemented in the November LTS. So on that note, 2.426 has been the choice or is the choice for the next LTS baseline. In the point one version will be released on November 15th, 2023. Next, we have Hacktoberfest 2023. So again, just stats to report from this week. Jean-Marc Massin has been doing a great job of providing this information. So it looks like we almost doubled as far as total number of PRs. Added a bunch of total Hacktoberfest PRs and a bunch of validated Hacktoberfest PRs and increased our contributor account, which is great. Seeing more people participate is exactly what we want and seeing those numbers steadily increase over time is beautiful. The spam rate's much lower than previous years even though it is still there. And the overall contribution rate has been a little bit lower, but this is a sentiment that seems to be across multiple projects. So it's not just Jenkins in this case. Who knows what that could be the cause from, but we were getting a lot of participation and we're happy with everything that's come out so far. So thank you very much and continue and keep it up. The documentation update for Debian packages. So again, this was in reference to PolarQuest that we've looked at previously. So this is the idea of updating the instructions to use Wget instead of curl. The user stated that they didn't have curl installed. So this was a really tough process to follow for them. Their suggestion is one that makes it appear more universal and more commonly used. So we've gone ahead and updated this and thanks to Damian de Portal for backporting the documentation change as well to the LTS page. So now the packaging site uses this set of commands as opposed to curl commands that were there previously. So thanks very much to the user, the contributor who submitted that and yeah, appreciate that. Generated a lot of good discussion and we've got things updated. Next up is the Jenkins Governance Board and officer elections for 2023. So the election process is in full swing. Voter registration is open. It's open until November 5th. So plenty of time to register for that. There is a specific voter registration group to join as well. This guy here. So as you can see, this would say join if you're not already a member. Mine says leave, which I'm not gonna do. But yeah, and thanks to Alexander Brandes and Umi Haffner for running the elections this year. Lots of work goes into that and just really appreciate the efforts that they're doing in keeping this rolling. Yep, and we have a few days if you want to nominate someone for, yeah, and you can even nominate yourself if you feel like so. Yeah, that's true. We have another week, a nomination period does close on October 27th and right now while we do have one nominee for each open seat, it's not necessarily an election if we don't have multiple candidates to vote for. So if you have any ideas, if there's anyone that you have on mine that you'd like to nominate, please feel free. The process is outlined in the blog post that Alex Brandes had submitted recently and we published back in September. So check that out for any further information that you might need. And if it comes down to we don't get further nominations, it may mirror last year's election where we did not have a vote because there was only one nominee for each position. There was no need to have that vote. So if we are lacking nominations that could be a very familiar place that we're in this year. The September new newsletter was published just, yeah, last week and last week. Yeah, this day, actually last Thursday. So, typical updates, information about voting and infrastructure updates, all the platform updates. Thank you to Bruno and everyone else, all the platform or all the SIG leaders for submitting their updates. As always, it's great to have this pulse on the community. Next up, so the ongoing Java discussion that we've been having. So previously when we last met, we did not have a Jenkins enhancement proposal submitted. Mark has gone and submitted that. So we now have the official 2 plus 2 plus 2 Java support plan for Jenkins in a JEP. This also includes all the existing documentation that we've been sharing and looking at over the last few weeks. So the Google doc, the diagram that shows the timeframes and even the recording of the governance board discussing this. So even further resources are here. And yeah, the discussion is being generated, which is really nice. People are commenting and this is moving. So this is fantastic, great to see. And now that we have the JEP, we can have all of those conversations and discussions here in one place for not only ease, but also just to keep everything organized. And the overall idea as we've discussed before is that the support for Java would be two years of the current one with introducing the next one for that same two years. The next two years, the previous one would fall off. The next version would become the required version. And then the next version after that would be in the preview. And then two years after that, we're dropping and moving and so forth and so on. So basically we get on this cadence of every two years we're moving forward and going to the next step. This gets us in line with all the other projects and platforms out there as far as they're supporting for all these goes, especially stuff like Java 11, which will be end of life next year. So as part of the ongoing discussion and the ongoing work to get Java 21 into Jenkins, which we do now, Java will have a blog post that'll be coming up discussing a lot more of this in depth, but also sharing kind of what those plans look like as far as we've got them figured out now. So more to come on that, but this is fantastic and now that we have a JEP, we have some place that we can contain all these conversations and all this information. Thank you very, very much to Mark for again, for doing that. This is fantastic. His draft was already interesting in itself. His proposal is really interesting. And this discussion is much better because I couldn't see much traction on the draft. People were saying, yes, no, whatever. And now people are giving their opinion on what they think about it. I think that's pretty cool. And even with the schema, I still have some trouble wrapping my head around that, but it will come. A few months ago, we were still with JDK8 and now moving to 21. This is accelerating and that's pretty cool. Yeah, it's gearing up really fast now that you mentioned it, Bruno. I hadn't really considered that we just got rid of Java 8 and now we're already talking Java 21. That's such a drastically, yeah. But yeah, no, you're absolutely spot on. It's really great that we have everything in one place and it may not make sense right now, but there's so much time before we even get to that point. So plenty of time to understand. And I think from my perspective, having the Google Doc is one thing because it's a Google Doc, you can read through it. It doesn't necessarily provide a conversation space like that though, whereas the Jeff definitely has that. Anyone can comment, et cetera, et cetera. So I think it's one thing to have the Google Doc and the diagram and the hypotheticals so that we can discuss, but now it's real, so to speak. It's a hard and fast place. People can go to actually reference this and talk about it and point to things and stuff. So I think it's just something that'll come along naturally with time, frankly. Yeah, we're looking forward to it next up. So the update CLI discussion, so... One more. Yeah, Shameless plug once more. Yeah, correct. This has been a recurring subject, using updates.li to keep jenkin.io up to date. Which one, Daniel, or something? Okay, I have another one, which is a follow up to this one, but yes, I had the first iteration where I was updating, I thought, all the references to Jenkins LGS versions in the documentation. And then, very boldly, I removed a Ruby script that was taking care of a few pages to generate the versions for the documentation. And of course, it failed. In the end, we had some horrible thing like placeholder later splits showing up in the official documentation. My bad. So this pull request is an attempt to correct that. So I propose to use update CLI to address those funky versions that are referenced in some obscure part of the documentation. As for example, the last Jenkins version split, that means that when the last time, we extracted a code from the Jenkins core and made it into a plugin. So that's not Jenkins version you often reference to, but it does exist in the documentation. So to me, the added value of this PR is that we'll have a history changelog of what happened within the documentation. Because with a Ruby script, every time you merge a pull request could be on any subject on Jenkins.io, well, the version could be updated and you wouldn't even know about that. It's part of the end generated website, but the GitHub repo doesn't know about that. So the added value for me is that, a changelog, a history of what happened with those versions. And I think it goes well with Vandits to recreate version Jenkins.io. And today I made another PR, but it will make only sense once this one gets merged, if that ever happens. Because the thing is I have one update CLI manifest that tracks and updates Jenkins LTS versions, Jenkins Weekly versions, but also BOM, BOM version, the Plugin Bill of Material. And the Frequent Thesis get updated is not the same. Each time you get a new LTS, you don't get a BOM version. Each time you get a new BOM version, you don't get a new LTS. So I made them into, stupidly, I made them into the same update CLI manifest. And that was an error. Update CLI generated this week PR, that was about the title wall, update the Jenkins LTS version to 2.414.2 in various parts of the documentation and the content, the modified file, were about modifying BOM versions. So that does not work. And Mark waits, spoils the update. Okay, the content is good, but the title is misleading. That's not what we're doing. So the next PR I made today is about splitting the manifest into two, one dealing with BOM versions and one dealing with Jenkins LTS, Weekly and Split versions. Ooh, that was a long explanation, sorry for that. No, no, apologies. Thank you very much for clarifying and we've been sharing all that insight for that helps paint that picture a lot better. And I think that's great that we'd have a change log of things that aren't necessarily, like you said, normally documented or anything that's like found or easily accessible, things that we don't have logs for at this point in time. Having that insight is huge and makes our lives easier or something happens or something gets changed incorrectly or something. We can look at a specific point in time in a specific action and figure that out. So I think that's great. And I think as far as the actions that it's taking and going through and updating everything, yeah, I can definitely see where having everything in one action would be a little confusing for it. But the fact that it's doing it and it's doing it successfully, my dad is great and really encouraging. So I'm all for it. And I think that having something that would allow us to track those changes and track that sort of information would be like really valuable. Well, thank you, Gaby. Yeah, of course. What was your inspiration for this Bruno, by the way? Inspiration? Yeah, I was just curious. Because I know you've been advocating for the update CLI stuff since you started making these, I was curious, yeah. It's a kind of love and hate relationship with update CLI because sometimes he's doing wonder for me and I do love it. And sometimes I just scratch my head and can't wrap my head up around the whole concept of update CLI. There is some magic in it. But the thing that started it all is that I was frustrated. I tried to maintain a few plugins and update them thanks to the fantastic tutorial of Mark and Deryn, I guess. But there is some inconsistency in that tutorial because sometimes we refer at Jenkins 401.3 version and later on we refer to 2.387. Something that's correct and it's because it's human maintained and I just thought to myself, we can't continue like that. We have to automate something because it's a burden for the person who's in charge of maintaining that. And it's not always up to date and it's misleading for the end users. Yeah, that makes total sense. Yeah, that's beautiful. Thank you very much. That's very community forward and really very much appreciated. Thank you. Thank you. Okay, great. So last item on the agenda is just to again, share that Docs Office Hours Asia is canceled for this evening. Today, tonight, whatever it might be, Mark is at DevOps World Tour and is not able to make it. I wanna say that he is out of office in the next week or the week after, but I could be making things up and I don't wanna lie. So Docs Office Hours Asia will be determined. So yeah, it will happen when it will happen. Stay tuned. That's all I have at this point. I don't know for sure, but yeah. No, so that covers the agenda that we have for the day. If there is nothing else to discuss or anything else that anyone wants to put on there, we'll go ahead and stop the recording in just a second. It'll be available in 24 to 48 hours. And as always, thanks for joining. Take care, stay safe until, and we'll see you next week. Thank you, bye-bye. Yeah, bye.