 Hello, everyone. This is a Jenkins platform Sieg meeting. We're on the first day of August 2023 and today we have Kevin Martin's and Mark wait, thanks a lot for coming we have two option action items, then we'll see what has been done lately and What is ongoing? Then we may have news. I'm happy that you're there mark You may say a word to about the end of life operating systems on the open action items I have a question first. What about two weeks from now so August the 15th Will be on PTO and even maybe not at home that I'm that important for that meeting But would you like to run it or should we cancel it? I Can hear you mark you are muted. I'm out of the office that day as well. I propose we cancel It's August. Hey, I want I covet to be more like you're at my European friends who I have some friends You take the month of August off the whole month and I like that attitude. So I think we should cancel the meeting Thanks a lot mark I'm afraid this is all new because I don't have access to the agenda If if we agree I have access to the agenda. I'll go cancel it immediately. Thanks a lot mark Then as always the other open action item is Docker image is of course the container image depreciation for the blue ocean container is Something to announce properly to the end user and it hasn't been done correctly yet Now What has been done the last two weeks? I've seen a lot of work on the agent and control images Unfortunately, have a did most of the work and he's not less in is not there to testify So unless mark or Kevin know lots of things about what have a did We'll just say a few words about that So what I've seen on the SSH agent is that a lot of versions got bumped up with looking to just one release 5.8.0. We saw the new I don't know if the name version is a correct term I don't think so. It's still both. I what is it a snapshot mark? How should we call that? You know because we updated the bullseye version, it's it's the operating system version. So I think version is fine Okay Thank you Next I saw something about JDK 17. I think we reached the Dash 9 something so it's a minor update and then get that you love so much mark has been updated for Windows and it was a good thing to do because I think it was way way outdated. Am I right? No, well as far as I know we're keeping it relatively current, but No way no matter. It's a good thing to update it command line get is a is an important part of many many uses of Jenkins Got it my bad. Sorry Then of the Docker agents there were also lots of version berms We had to release it these last two weeks So we bumped up the our client version of course bullseye also the version of Jenkins remoting JDK 17, JDK 11 and get on Windows 2 For in-boot agents we also had a few version bumps and some new images resulting in two new releases. We have The Jenkins agent that got bumped of course. So because it's the root Docker image We are basing inbound agent on and we also have new mages for Windows 2022, which is a good thing I don't know if somebody in the community was waiting for that Created it nonetheless. Yeah. Yes, there's there's lots of interest in it actually so Windows 2018 is reaching nearing end of life So lots of interest may be too strong, but Windows 2018 really is 18 Well, whatever whatever 1809 means because there really probably isn't a 2018 but the 1809 container image is Hey, now many years out of date Yeah, oh Sorry Yeah, got it and the controller of course got three new releases following the Jenkins path But we have nonetheless new versions of JDK 11 and 17 and of course the Balsai version got bumped Now on to the ongoing work on SSH agent. I saw that Git LFS version was a work in progress There's also a kind of old Pull requests from a new contributor to build the SSH agent for Debian bookworm. I Said I wanted to help, but they don't find the time to so I wrote a message this week I guess asking the user what kind of help I could bring but didn't get any answer yet Then we have also Switch to the open SSH installation to the windows native SSH Which could be a breaking change, but this one hasn't been updated. You know why I think Mark anything to add to this one No the Well, actually take it back. Yes, there's still a question about how we name containers And the container naming thing is At least peripherally involved in the question because because We've got on the controller side. We don't encode the operating system name Consistently into the image But on the agent side we do because we have more agent more more os names the question ultimately is Should we adopt a consistent naming pattern? Agents and controllers et cetera, but that's a bigger question than just the agents right now. We hold with a pattern. We have I see so do you see a set of images where You would say that it is Consistently named or if there um repo we should take example on I I don't I don't have Strong opinions one way or the other. I know there are strengths and weaknesses to each convention. I think we've got Workable things both for container for the controller and for the agents Right the users of the agents know what labels to what names to use and the users of the controllers know what names to use it's just a little Surprising sometimes that they use a slightly different naming convention Yes, and Lately I've been installing quite a lot of help tools into my ide and whenever I use some Jenkins dot something dot something That's something these tools tell me It doesn't sound really good. You should have a pinned version of some sort of just get rid of the divian You even don't say which divian you're using and so Yes, I think we could do better in a way or another I don't want to have That big of a name for an agent or a controller, but maybe we should say something more precise. I don't know I get your point. Thanks a lot Next one is on the docker agent. So there is some work ahead about windows nano server tags, but it won't change the Uh image themselves. It's just changing the way we tag the images Uh, then for the inbound agent, I thought this one was already done and my that was wrong So we are trying to sync the readme.md with what is appearing on docker hub And I think L there also is it working or is it Damian? Whatever on tracking the nmap version Which is used in windows test once more that will change the image itself just the building process And on the controller, there's a know PR about uninstalling a plugin. We ask the user for some changes. I think he done most of them So I think this one just needs a review once again The goal of this PR is just to change the readme file or add a dot md somewhere that explains how to install The uninstall a plugin when you are using docker And now it's heavily based on the article that the blog post that got published on jinkins.io a few weeks or months ago Time flies by. Wow Then uh last time we had this meeting. I said a few words about end of live operating systems and caness told us uh, what his point of view is and why so many people are stuck with old OSC that have reached more or less their end of life But they still have to use them because of um proprietary software most of the time Uh contracts so they're happy that um Operating system vendors keep on their support as long as you pay them, of course So mark you wrote a really nice blog post. I think I'll link to that. No, it's not the blog post It's your post on community dot jinkins.io, but Would you like to add anything to that? It just the the concept is it's a good thing for vendors Like red hat canonical microsoft that they correctly when their customers ask Offer to sell those customers a support product that extends the life of the thing They were previously supporting publicly To now have an additional support life and they require extra payment for that. It's very fair of them That's perfectly reasonable. However, the jinkins project has never Paid for additional support beyond the contracts beyond the end of life and given how we're We're a an open source community dependent on people contributing their time and their skill I don't think we should start doing that so Now that doesn't stop commercial entities from doing that kind of thing if they wish but The jinkins project itself should not extend beyond the public end of life because I can't imagine how I would persuade The people who maintain the various plug-ins in the jinkins Plug-in ecosystem that they need to go pay someone for an additional operating system contract in order to support It just doesn't feel right. No, you're I get it. And frankly you wrote that you're open to disagreement and I so no answer For the typing so We can encourage him Thank you I resisted the urge to add the dbn 17 dbn and gdk 17 installation because we already talked about that two weeks from now Kevin, would you like nonetheless to tell us something about that or is it Done finished merge. We don't talk about that anymore Uh, no, yeah, uh, so for the most part the work is done There's still the need to update the windows installation documentation specifically But that's more because it's using a much older version of jinkins than we would typically use in the documentation But there is a blog post that actually just went out today Just announcing the transition and the fact that we've made this transition That lists out some of the areas that the documentation has been updated And just gives some background on it. So for the most part it is completed it's really just that windows piece that we're we still need to figure out and It's something that i'm uh partnering up with It for just to see if I can get a machine myself to do that or You know if it comes down to obviously asking for help from the community. So Regardless, we'll get there and that'll be taken care of but yeah Thanks a lot for that That's all that I had I may have just a little subject, but we's not really Prepared so that may not work at all Kevin and mark would you have anything to add in the news or I actually had one item that I wanted to add to the to the page Because I just got some data from basal crow That I think is an interesting topic or an interesting thing to view So i'm going to just insert it if that's okay Oh, of course. Thank you. Here goes the picture Oh, all right Oh, so you have gdk version installations. Maybe exactly gdk use by date So if you put that on screen, so I think Oh it there. Sorry. Yes. It's on the next page. Okay, so so the the prompt for this is that I've sent a message to the Jenkins board and to jenkins officers including kevin as documentation officer And tim jocom as release officer proposing a To choose the when jenkins will stop supporting java 11 And when we will plan to start supporting java 21 And the the feedback thus far tim jocom says yep sounds like a good plan kevin said sounds like a good plan Um Uli Hofner has some concerns in terms of the developer experience that we're trying to work through But this graph shows What what we see as the common life cycle? All right, so the green line that you see there is java 8 usage And the date is all the way up through the end of july of 2023 so very recent data And but what we see is nicely tapering off of java 8 use Now when we say tapering off it's still 100 000 controllers running java 8, right? So taper taper is is all relative But it's a good story that what you see is java 11 is Clearly at the 150 000 point and java 17 is growing down at the bottom It's probably in the 30 to 40 000 range right now So the proposal that I sent suggested a series of steps Step one is choose the dates and the proposal is We will take jankin's end of life for java 11 to be october of 2024 When temeron ends their life of java 11 When red hat ends their life of java 11 and one month after microsoft ends their life of java 11 So so it's right in the time frame where three big vendors of java Platform items are all stopping their support of java 11. So the jankin's project The proposal is october 2024 one year from you know 14 months from now We will stop supporting java 11 now in order to get that to that date. We need to alert users And so the proposal is that in october of this year We will put a warning into jankin's weekly That says java 11 is going away at the end of october 2024 And that warning will appear to users giving them a year to Get themselves prepared if they're on weekly And if they are using lts 12 It will then cause it to arrive in december And so they will then see it in december and have about 10 months To get themselves prepared for that transition off of java 11 So the october the october introduction Is into weekly gives us enough lead time to be sure that it reaches the december Dot one release of the next lts after 414 So so then The next piece of the story is that we want my proposal was Let's set our objective to support java 21 in jankin's By end of october 2023 java 21 will release in september of 2023 So september 19 is the officially declared release date And about six weeks later the goal is at least by that point six weeks later have a jankin's weekly release that officially supports java 21 So the idea is a a phased approach We get java 21 supported in weekly and then the next lts and it may be the december lts or it may more likely be The the next lts three months later that includes 21 in lts It just depends on when we get the weekly supporting java 21 Okay, I guess basil has already done all the Calculation he may know how much effort we will have to push jankin's into the java 21 So, yeah, so so buzzle buzzle and others are already using java 21 early access as their primary java So, yeah, so so yes, you're correct. They're they're already people thinking about this Using the java 21 early access. However, we have to worry about jankin's infrastructure, right? We've got to have java 21 available on ci dot jankin's dot.io We've got to worry about container images. We've got to worry about installers We've got to worry about all sorts of things that are are more than just the developer experience before we're ready to say Yes, java 21 is good to go So we've got plenty of work to do but the picture looks pretty good that it's doable The infra team has agreed they'll they think they can make it no problem with java 21 infrastructure well before the end of october And and so we're looking forward to it Yeah, but we'll have to educate if they don't educate themselves The core developers to gdk 21 and of course plug-in developers and so on i've read This morning Some code some java code that used to work for java 11 that doesn't work anymore with java 21 or that does something else or even doesn't compile So yes, there is quite a lot of work ahead. Maybe not that hard for people already experimenting with java 21, but for Normal developers like I am I guess I will have to educate myself before Pushing my plugins to gdk 21 Well, and and as a matter of practicality You really won't push your plugins to use java 21 features for quite a while Yeah, right because when we support java 21 when we start that When when our when that purple line that is java 17 on this graph becomes a java 21 line During that time we'll still be delivering java 11 code And building java 11 bytecode so you can't use java 21 features in that code unless you're willing to lock your users out of running java 11 or java 17 And and so and that's that's uncommon. We don't want to lock users out. That's not a healthy thing to do of course We're almost running out of time, but I have still one question which is Linked to that as I said before it's not really prepared But earlier last weekend I was trying to install Jenkins on the machine only having a gdk 21 Or was it 20? Yeah, 20. Sorry um And Jenkins refused to install because it was not As I read in the log, uh, recognizing the pattern of the gdk version name So, okay, it's something that is hard coded or bundled in no no There's a there's a known command line argument that you can use that will tell Jenkins to broaden It's a loud range of versions that it's willing to accept I think it's enable future So if you just do a minus minus help on your command line It will tell you if you really mean it that you want to run on on A more recent java version or a different java version Then then there's this I think it's enable future, but minus minus help will tell you Okay, but that if you are installing Jenkins by hand, what about APT get or something? Is it doable also on? Yeah, because it's just a command line argument So what you do is you you run apt get Right, so you do the install then you have to do system control minus minus edit Jenkins Or system control edit Jenkins. I forget if there are two minuses But system control edit Jenkins and then you adjust the command line arguments of that Jenkins service So that you can pass this additional command line argument that says I want to enable future java Oh, that's good. Thanks a lot for your insights Because as you already know, I've managed to have a Jenkins agent on risks five And this time I'm trying to install on the server the Jenkins controller So that may help me with that. Oh That's cool Thanks a lot. I'm afraid we are out of time. Thanks a lot for this Picture this graph. It's really exciting to see where we're going to The video should be available from 24 to 48 eight hours to go to say and so Two weeks from now. No meetings. So see you at the end of august Until then enjoy Jenkins And your time off if ever you have some see you later. Thanks a lot for your time. Bye. Bye Thanks. Bye