 one. Hello, good afternoon and good evening and welcome to the Jenkins documentation office hours. Today is the September 21 edition and this is the EU US time slot. Today we have myself, Bruno Roxton and Mark Wade as joined. So welcome and thank you for joining us. On the agenda today, some announcements and blog posts that just came out about Hechtroberfest 2023 and the Jenkins governance board elections this year. Some updates on Google Summer of Code, some pointers on the Java proposal that we've been discussing for the last few weeks. The addition of the platform information section, which I've been working on. Just a quick couple of notes on DevOps World Tour and something that we've been discussing again last few weeks, describing the process of choosing a plug and bomb and just a short note on the August newsletter. Is there anything else that needs to be added to the agenda today or anything else anyone would like to put on there? Nothing I can think of, thank you. And nothing for me. Okay, thank you very much. So to get things started, so Hechtroberfest 2023 is going to be here very shortly. We just published a blog post for announcing it from Jean-Marc Massin. So just going over Hechtroberfest, what to expect, what the process is going to look like this year, and just what to end up just the kind of nice to have the resources for contributors and maintainers and some notes about what differences there are going to be this year. So it's the 10th anniversary, which is really exciting. And one of the biggest changes this year is that there isn't going to be a physical swag or t-shirt reward. It will be a digital reward kit and the first 50,000 participants to complete for pull requests will have a tree planted in their name. So really exciting, really a little different, but still Hechtroberfest has always been a really watermarked event for Jenkins. So really excited to have that happen again this year. Next up, so the Jenkins governance board and officer elections season is upon us. The nominations and voter registration period opened up on September 18th, so just a few days ago now. And the nomination period will extend to October 27th, while voter registration goes until November 5th. Once those periods have passed, voting will start and we'll get to see what the future holds for our governance board and officers. Just to be very clear, the election voter 2023 group is an esthetic if you want to register and vote in this year's election. Every year uses a different group. So you can check out the blog post and if you navigate to the group here, mine says leave, but if you're not a part of the group, it will say join and you can join in here so that you will be part of the election process. Two governance boards and all five officer positions are up for election as they are, the officer positions every year. And yeah, and then the post has other key dates and other information. But when we get closer to the actual election time and results, there will be other communications to be had. The blog post also shares some ways to contribute and participate. As part of the voting process, we are encouraging everyone that they've contributed to Jenkins. We're not requiring any sort of proof or validation of that, but the idea is that if you're participating that you're part of the community. And thanks to Alexander Brandes for putting that together and posting that. Thanks to Alex and Julie Hafner for running the elections this year. Next up. So the Google Summer of Code is approaching an end. We've got two projects that have fully completed and two that are have been extended that will be completed in the next couple of weeks. So really, really exciting there. Thanks to all of the participants, mentors, or Gadmonds, everyone that's been a part of Google Summer of Code as it is every year. Wildly important and crucial to the community and very successful. And the final presentations were done last week in the Jenkins online meetup. So that recording is available here and on the Jenkins YouTube channel. So if you want to see direct insights and details from the participants about their projects, you can view them there. As a quick overview. So the Docker compose for tutorials has been completed as a project, does need some more work to deploy and include in the documentation. But it's there and potentially during Hacktoberfest could be something that gets worked on with the upper team, but no guarantees there. The building Jenkins.io with alternative build tools project is still being worked on, but the goal is there. Vandy has been doing a lot of work on this. They've had to do a couple of pivots for stuff like Gatsby, but they're getting a lot of work done there. They have their navigation has been sorted for the most part. The demo sites available to view and check out. But amazing work here. It looks really great. And I'm excited to use the new site for the documentation. The GitLab plugin modernization. Bruno, I forgot. I didn't check. Is this one completed or is this one of the one that's extended that will be finished in the next couple of weeks? So the project is finished, but the code is not merged to the plugin yet. It's the story that's there is correct that I've still got interactive testing that has to be done. And then once we've completed the interactive testing, we'll merge to the main line and release a new version. Great. Thank you very much, Mark. And for the plugin health score, so we've had several blog posts that degrees put together and written for us published detailing the different probes that they've been working on in that project. So there's the renovate probe. There is the JSR 305 probe. There's just, yeah, the JSR 305 probe, number of open issues probe. So lots of work being done there by Jigridi. That's also finishing up and I think is going to be finishing up in the next couple of weeks. So again, just fantastic work. Thanks to everyone for their dedication and their efforts in this. Really great to see the results. Next up. So the Java 1117 and 21 discussion that has been ongoing for some time now, continuing to be developed. This is a proposal that is still moving and still being worked on. So some things that we've actually, Mark, would you mind providing some insight and background on this just so it's nice and clear. I don't want to misspeak. Yeah. So the proposal is a two plus two plus two support model for Java. Java delivers a new long-term support release every two years. And that clock is something they've committed to and they did it in Java 17 in 2021. They've done it now with Java 21 in 2023. And we fully expect that they'll do it again with Java 25 in 2025. By being on this clock of every two years releasing, that means and with a six year release cycle, that means that Java versions are supported by, they're up to three versions of Java supported by Eclipse, Temeron and OpenJDK at any one time. And the Jenkins developers have said, hey, three Java versions is too many. So what this proposes is to support at one time. So this proposes a general model that says we'll support Java, a new Java version for the first two years of its life. In the second two years of its life, so years three and four, we will make that Java version the minimum required Java version. And in the last two years of the life of a Java release, that Jenkins will no longer run on that Java version. That way we're only supporting two Java versions at one time. This oddly enough aligns somewhat with Oracle's commercial support thing that they do. They for the first two years of their license say, hey, well, you can use it for free in the first two years. In the third year, you can also use it for free. But after that, you have to buy a license from us. Now Jenkins doesn't rely on Oracle's JDK. We use OpenJDK and Eclipse, Temeron. But the notion that we don't support something all the way through the end of the life of the JDK in order to reduce our burden is a fair behavior. What we've got is a transition period from the current world we're in right now with Java 11, where we'll support it all the way until Java 11 reaches end of life. Java 11 will no longer be supported by the upstream providers in October of 2024. We'll make this transition then to make Java 17 our minimum version for a 12-month period. Then switch over and make Java 21 the minimum version for an 18-month period. Then with Java 25, we're on to the clock finally of two years supported but not required minimum, two years required minimum, two years no longer supported. Does that give enough of an explanation, Kevin? Yeah, definitely. I think so. Mark, that's very clear and they explained everything. Thank you very much. Okay. Some things to note about the proposal. This has been sent out to the developer's list, governance board, officers. Everyone is very much on board with this plan and approves of it. It is something that everyone's in agreement on and looks to be what we're moving towards. To have the developers and others really backing it up is exciting. They have to deal with this directly. Having their encouragement and their backing is really nice to have. Next up on the agenda, something that we've been discussing and I've been working on is adding a platform information section to the Jenkins documentation. This is just a place to consolidate and contain things like the support policies that we offer and then additionally things like Java upgrade instructions and other parts of platform information. I've been able to submit the pull request. Mark's gone through, reviewed it, has provided some notes and some changes for me that I needed to take care of. I've also provided it to my docs team that they've been able to review it as well. I'm going through and applying updates as needed. I'm hoping that I can get this all taken care of and have an updated version available to review. Then the idea is that this will sit in the documentation so that there is a section dedicated to the support policies so that users don't necessarily have to go to the installing documentation just to get some of these. It also again consolidates the Java information there are upgrade guidelines that again are not necessarily in a dedicated spot so this gives them a home. On that note as well with Java 21 being released just this week, that's another set of upgrade instructions that will be added to that as well. From preliminary looks right now, it doesn't seem to be different from the Java 17 instructions but something else to include. Next up, so DevOps World Tour has officially kicked off. Last week was the first conference, the 13th and the 14th which Mark attended and gave a talk during. There's still time to register for the Chicago and Santa Clara events and there's also the Singapore event and then the London event as well. I think the London event has changed dates and the Singapore one is still happening but it looks like it is now free registration for the Singapore event. That's for sure but I just saw the date that has moved for London. It's the 5th of December now instead of the 29th of November. Thank you very much Bruno. Mark gave us talk there, the business benefits of contributing to open source. He said he had a really great experience. Mark, do you want to share any insights from the conference? It was a great conference. Thoroughly enjoyed it and the talk was well received. Had five people who met with me afterwards and said I want to adopt a plugin. That's good. Fantastic. Thank you very much. Next up, how to describe the process of choosing a plugin bomb version. We've been discussing this for the last few weeks. There hasn't necessarily been any progress on getting this implemented or changing this but we have been having that conversation to decide what possibilities there are. There's opportunities to make sure that everything is aligned so that we can cut down on confusion or any kind of incompatibility mistakes that folks might make. I am guilty of reading things too fast sometimes and everything is blurred together or I misread something. Having a very clearly stated version for some of this stuff would make a big difference in those cases. Bruno, did you want to share anything that we discussed earlier or no? I just wanted to say that I played guilty. I wrote some inconsistent bomb.xml because it was not crystal clear for me which version of bomb versus Jenkins version I should choose. Maybe the doc exists somewhere but frankly I was puzzled. I read too quickly. Yesterday again, thanks a lot Mark for helping by the way and sorry to have made you lose your time because I hadn't read correctly the update a plugin tutorial and I quickly pointed finger at the panda about saying the butt did the bad thing and no it was me just because I read too fast and didn't think twice. I just copied paste and forgot about it so if somewhere there could be a definitive guide on how to choose your bomb version related to your Jenkins version and so on yeah that would help people like me but I don't think there are so many people like me who try to maintain a plugin while not understanding what they are doing anyhow. Actually I think there are a lot of people exactly like that and so the improve a plugin tutorial needs I look at it now and it needs improvements certainly and insertion of correct values etc. There's plenty to be improved there so yeah and I think the earlier question you noted of how do you choose the plugin bill of materials version is one that was raised as an issue in the plugin bill of materials repository and we haven't resolved it yet. It's a it's a good issue and it needs it needs resolving. Yeah and I was not trying to say that the update to plugin tutorial was badly written in that specific section it's just that it's written that you should make your brain work and find the correct version which I didn't do so I just copied and paste and that's my mistake. Well but but actually the plugin the plugin tutorial the improve a plugin tutorial is in almost every other case exactly plugin play is exactly copy and paste and so by having this case where we say oh no you must apply intense human thought I think instead it'll be better for us if we if we make this one also very easy to copy and paste because we've got the we've got the data elsewhere in the pages about which Jenkins version we're recommending. It's just we haven't done the work yet to make that tutorial adapt to that information because the choosing a Jenkins version page is automatically updated whenever we release a new LTS and that automatic update could as readily apply to the tutorial as it does currently to that choosing a Jenkins version page so there's there's truly no reason why we can't make that choosing a or make that plugin bill of materials page as smart as the choosing a Jenkins version page. Okay got it. It's already yeah it's already working for choosing the right Jenkins version but it's not with update CLI it's with another thing. No no I think it's actually using well sort of so let's let's see what it is so Kevin open up that page let's look at what the page says so if I think if you go back up a page or two from where you were. Yeah this one okay this page has inside of it and scroll down a little further Kevin we'll see numbers yeah there we go so this currently recommended version thing chooses the current LTS as the one it says could also consider the preceding LTS and the one before that are both in the earlier sentence all under currently recommended versions and those are injected automatically and so that version number and it's it's done by I forget what the technique is it's some Ruby code that reads from a from from a I think from update center to figure out what the most recent releases are but but this same technique there's no reason it can't be applied elsewhere it just isn't currently applied elsewhere. Okay or if ever I could find the source of truth I could maybe try it with update CLI because I'm already using some other parts of the documentation but yeah and that's that's a valid point because the the update CLI code might be able to read the data source here and do a better job of updating this page so that instead of generating the page at inserting the content at page generation time we insert the content through poll requests that are intentionally placed so now I apologize I have to drop off for another meeting but thank you Mark but this one this one is very much a Bruno you discovered a very real problem it is that choosing a Jenkins bill of materials version is more difficult than it should be and and it highlights hints at other areas yeah thank you Mark bye bye okay thanks mark take care uh so yeah um also I just noticed we're a little off but that's it's okay yeah it might not be recommended yet it's automatic but we don't know how often it's run yeah so we officially are on two point uh two or three two I guess point yeah we're on point two now um yeah because yesterday we just had the release and it was a the security release yesterday um yeah for both weekly and LTS so uh yeah those things were updated but um yeah none uh like Mark said I think that's a really great issue to point out and how it gives us something to work on and uh I think like he was saying opens the door to see like what else we could do to help that kind of thing or what other you know gaps there might be where we can fill them in like that so yeah thanks very much Bruno you're welcome more work to do um that's cool we love it you know each and every time in the Jenkins community when a point finger or something say oh it doesn't work it ends up with maybe you should open a PR but that's cool because I'm learning a lot yeah the finger that you're pointing gets immediately pointed yeah makes me think of you know those spider-man pointing a finger a spider-man yeah exactly I did it no you didn't you didn't yeah great uh cool and then uh last thing I have on the agenda just um August newsletter is currently submitted as a progress once it gets um I think there's one or two other updates that need to just be added to it but once it's done um that'll be published and we'll have that out on blog cool uh I guess was a little bit slower so it's not as much content from all the sigs but uh there will be a newsletter regardless yeah cool uh doesn't that is there anything else that you'd want to discuss Bruno or thread on the agenda no thank you Kevin I think we covered all I had in mind okay great uh so I'll go ahead and stop the recording in just a moment then in that case thank you as always for joining uh recording will be available 24 to 48 hours uh once we wrap up here and uh yeah until next week take care thanks for joining again and uh have a good rest of your day bye