 Go. Hello and welcome. This is a Jenkins platform SIG meeting for January, 2023, the 30th. Happy New Year. If you haven't had Happy New Year already, tons of times. Thanks a lot for being there Mark and Kevin. Today we have a light agenda. We have some open action items. We have some news about the doggery mages. We'll maybe find just a little slot to talk about blue ocean containers because there are no really new news. And we'll talk about Gibbon 12 and other JDK support for Jenkins and what's new in the containers world for Jenkins and so on. So first of all, we have to find a better time for this meeting in order to get some more people to join us. So Mark, should we schedule a doodle or use another tool to do that? Yeah, doodle has worked well for me. And I'd lobby in favor of doodle just announce in the developer mailing list that we're looking for a new time for the meeting, post the link to the doodle, and encourage people to reply. OK. So may I put the action item on you? Yes, absolutely. Oh, thanks a lot. I could have done it. It's easy. I'm happy to do it. Thanks for your help. Then the next open item was really the platform support containers we had to add Windows 2022. And I think we can get rid of that because later on in the document it's written. Stefan Moul worked on that the previous weeks and we now have Windows 2022 available for Azure, I think. And AWS VMs will come later on. OK, no news about the two architectures. I don't know if the fix for Windows 2019 has been done or not. Does any one of you has any information on that? I don't. I'm not sure what fix Windows 2019 would mean in this case. What it's really saying is we have to have an old image, it was an old image or something like one year. And so it was broken somewhere. I don't think it has been unbroken fixed because we will switch to Windows 2022 anyway. So I think. Right. OK. Now the Windows container support is not going to disappear. Yes, of course, but we'll see. It was easier than expected. I think migrating to Windows 2022. And we still have now that it's available for everybody. We have to know if people will use it and if they will have some problems or not. We'll see. We don't have yet the Docker image download statistics. Unfortunately, we'd like to have them for the platform and the version to see if it's worth it to continue supporting exotic OS, for example, like our Kleinox or even Alpine, who knows, or even for ARM32. Is there anybody except me who is using ARM32 Docker images? I just don't know. So if that's possible, one day, that would be cool to have them. I don't think there has been any progress on the gathering and exploiting of statistics. Thanks to Damian and Jean-Marc Mason. I heard nothing about that. Yeah. Right. No hurry. Anyhow. What else? Nothing really new, in fact. I already told you about the Windows 2022. And we're still thinking about adding Wolfie, duplicate Aucklanders. As long as we don't have the statistics, we can't make a decision, I guess. Right. Ahead of time, we don't really need that. But I wanted to make the test. So I'm progressing with RISC-5 agents with JDK-17. The thing is that the JDK that is supplied with Debian and Ubuntu in the latest versions is 0VM. I'm not at all a specialist of JDK and GVM, but it looks like it's interpreted. It's not hotspot. It's not jit. It's just it's not compiled. You know, it's interpreted. So it's very, very, very slow. And that's not a really good thing. But that's the one which are built by Ubuntu and or Debian. But the JDK-1920, which are built by Timurin, are hotspot versions which are much, much quicker. And there are even people in the wild building by themselves JDK-1920 with hotspot for RISC-64, because we need that. So I'm progressing, but not everything is just about perfect yet. OK. So that's an interesting outcome that matches with the experience that was had with System 390, where, yeah, with System 390, Java 8 was initially only available as a 0VM. And therefore, it was abysmally, unacceptably, totally and completely slow. What IBM did is they then created a new project to do an alternate Java 8 VM that happened to run much better on System 390. I forget the name of it again. It was Semaru. It's now called Semaru. Open J9. That's it. Open J9 is the famous. The famous Open J9. Right, Open J9. It was a result of that. It's interesting that this is playing out again now with the new CPU architecture, RISC-5. So 0VM. And really, nobody's done a hotspot JDK-17 yet for RISC-5. No. OK. So that tells me that our likely ultimate target will be JDK-21 when Jenkins supports JDK-21. So that's cool. Good, and experimenting with 19 or 20 would be good things to do, because running Jenkins agents with 0VM, at least for me on System 390, was completely unacceptable. It just didn't work. It was so slow. It works, but you have to be very patient. And I've seen a performance gain of 4x to 8x when using the non-0VM, the hotspot VM. Not so bad. Then we haven't progressed, sorry, on the container image deprecation for blue ocean container as far as I know, so we can skip that subject. I don't think we have progressed in the container repository management for Jenkins agent either. OK. Yeah, I think what I was referring to earlier with Windows 2019 is that it's been one year and the control Docker images are not up to date. But maybe I'm totally mixing things that are not related. I don't know. I'm not a specialist of Windows and Windows container. Next, oh, Mark, you showed us earlier this week in the documentation submitting, I think, that the DBN12 called Bookworm will not deliver OpenJDK11 by default. And that it is planned for release in 2023, but March 14 or something like that. I can't remember if it's freezed or not. Yeah, so March is the freeze date. Likely release April, May, or June, right? They wisely do not commit to a release date. But going through these freezes, if I remember right, the last freezes were typically 4 to 8 weeks. OK, got it. So what does it mean for Jenkins in general and for the Docker images? Yeah, so for the containers, it actually doesn't mean anything at all because we depend on Eclipse Temerun. And since we're using Temerun, we'll continue to bundle. We'll likely update to Bookworm and we'll continue bundling Temerun 11 and Temerun 17 in two different container images. But it will cause an update to our installation instructions. So and the proposal in Docs Office Hours was we'll make Java 17 the recommended Java version on Debian and Ubuntu operating systems with as soon as Debian 12 releases. That way we don't have to have two sets of instructions. One that says for anything older than Debian 12, use this, we'll just have a single set of instructions. And it says, use Java 17. It's fully supported and why not? Cool. So we've got work ahead of us regarding documentation, but be doable. OK, does not affect Docker containers, of course. Now, JDK support for Jenkins, no news from the required Java 11s. A few people still discover sometime that they have to migrate to JDK 11 with recent version. We can see that on Community Discourse IO, but most of the time people just migrated. We've seen the latest graph found or created by Bazil Chrome. And yeah, we have more Jenkins controller with JDK 11 than JDK 8 now. And that can't change anymore. That's what we wanted to. And we have to accelerate, by the way, because JDK 19 is already almost out of date. 20 is almost done. We have to prepare ourselves for 21. So it will never end. That's a lot of work, but that's cool. We are all not as late as what we used to be. It's getting better and better. That's nice. Now, S319x is back. Mark, can you tell us more about that? Sure. So IBM has kindly donated a virtual machine for us that we have connected to ci.jankins.io. And some of their people also created a series of acceptance tests that run on ci.jankins.io that confirm that Jenkins installs on System 390 and does basic install. It also hosts Docker containers running System 390 Docker containers. And we use that to test Debian install with the LTS and Debian install with weekly. So we are actively testing System 390 with Jenkins controllers and we're running a Jenkins agent. Oh, that's pretty cool. I've never seen one for real S319. Even don't know if I know what it looks like. Anyhow, that's pretty cool. And that means that it runs with OpenJNF. How did you call that earlier? No, and see, that's the nice thing, is Java 11 on System 390 has hotspot. So does Java 17. It was only Java 8 that had to do OpenJ9. And thus, as you look back in the notes for the platform sake, there was a period a year or two ago when we actively worked on OpenJ9 in order to do if we had to System 390. Interests in OpenJ9 tapered off when hotspot Java 11 was supported on System 390. And we stopped about six or 12 months ago. Any platform sake work on OpenJ9, just because there aren't enough people in the SIG interested in OpenJ9. It's an interesting hobbyist thing. But we only get to do so many hobbyist things and at any one time. I know what you mean. For sure. Thank you, Mark. Then we have the infamous series of bugs, sorry, bugs that publishes all versions of containers. Damian has been chaining them like a madman for a month and he keeps coming back. I think he's got a track now. He knows what to do and a contrib user just opened a bug a few weeks ago, I guess, last week. Because once again, the problem is back. The issue is once again there. But I think Damian now knows how to tackle this. He will get help from the rest of the infrared team meeting and that should be solved hopefully very soon. I think I heard you talk about that earlier this week in another meeting, Mark. I think you have the problem if you use the latest tag. But if you use a precise tag, which is not latest, you should not face the issue. And one thing I heard was friends don't let friends use latest, which I love. Yeah, the special cases where latest makes sense are also cases where you accept that if latest is not exactly what you want, that's the way things go. That is unfortunate, very sad, but there's not much to do about it because in other projects, latest could mean the tip of the weekly build or the tip of the daily build or the tip of the master branch or it could mean the latest release of some ancient version. Latest is ambiguous, whereas a precise version number is not ambiguous. That's why in the documentation on Jenkins.io, we always use a version number with only very few exceptions. Version numbers are really, really helpful. Yes, it did. Damian is very strict about that. He kicked me in the head a few months ago, but very much benevolent. It wasn't hurting that much, saying, no, you've got to stop using latest for your project and using other people's latest. You have to think about idempotence. I don't know if the word exists in English, but no, yeah, each time you rebuild, you get something new, unpredictable, and that's bad. Listen, I don't use latest anymore. And if you ever see in my source code that I still use latest, you can kick me in the head. You're welcome. And it happens. Now, there has been minor a bit of agent images. I've seen a lot of commits lately, including Alpine 3.17.1 and Oclinux, nothing major, just following the new versions. And the LTS 2.375.2 went fine. Did I daydream or did I see Live with Darren Poppin regarding that LTS, or was it about the weekly release? We talked about the LTS just yesterday in a livestream, yes. That's what I thought. You don't have time to watch it yet. We cheated and also used the... We spent a bunch of time in that session talking about the accomplishments of the Jenkins project over the last 12 months. So we stole and wholeheartedly borrowed from the blog post that you and Kevin created. Oh, that's OK. Kevin put so much work into that recap that we have to talk about it just everywhere we can. Thanks a lot, Kevin, for that work. Yeah, that's amazing. I have rarely seen that many commits and back and forth in PR about documentation in Jenkins. So, yeah, congrats on that. Now, Stefan also made available JDK 19 for Jenkins in the infra and it's available for everybody. And of course, we are already thinking about JDK 20 because 19 is almost the end of life. I regularly ask for new reviews with the team or in people, you know what I'm saying? I'd like a new release because there are a few... No, we don't build anymore. We rarely build new JDK 19 because it's end of life. It's supposed to end this month or next month. So, no reason to do that. So, we have to move to JDK 20 as soon as we can and target JDK 21. Infra has also installed Maven 3.8.7. It's available globally. I've also installed it on my controllers and for the time being, everything is going smoothly. I'm really happy about that. I talk a lot. Did I forget anything before we close the meeting? Do you have any question, remark? No, those covered the topics that were on my mind. We made it. Thanks for hosting. Oh, you're welcome. Thanks a lot. The recording should be available from 24 to 48 hours. And until next time, have a great time with Jenkins. Bye-bye.