 Welcome to the Jenkins platform special interest group meeting. It's the 19th of November 2021 remember we abide by the Jenkins code of conduct be nice to each other. So topics I had on the agenda were Java eight end of life plan. And then let's see Java version updates or multi platform support blog. Java version updates and Docker image automation those were the only topics online this Tim are there any topics you wanted to be sure we covered. Nope. Okay, so so on the action items we've still got an open pull request for the plugin installation manager docs. That progress has been slowed because I've done no additional work on it. Got good use cases in it just some of them are incorrect and need need refinement before you publish it. Tim are you okay with the idea of putting plugin installation manager documentation on www.jankins.io would you rather we just point them to the read me and I don't want stuff that's going to change too much like only sky big PR to redo the command structure and in the CLI. It's fine. I, it's different. I can be fine to have an reference documentation and tutorials, but I, well, I would say tutorials is probably fine but I don't know how much detail that should really go on the website. Okay, so this particular pull request is look is trying to outline some use cases and it was it was helpful quite helpful to me because it pointed me to. Oh, this is how I solve the use cases I have, but it's probably got many more use cases than than may necessarily so how do you install it. How do you generate a list of plug ins how do you list the dependencies of a plug in how do you install a particular plugin. Those kind of things are those. Okay for www.jankins.io with short snippets on each or would you rather we just point them point them elsewhere and say hey go read it here and we'll propose them as pull request to the configuration to the, the tool itself. I think that probably belongs on the tool itself really. Okay, all right. I would benefit that it can be at least in the repository when the tool releases, we've got documentation associated with the tool. Yeah, I could be fine to have like a basic page that just gave the most common use case and then links off to the other docs, or even scraping the read me and including it on the website but I think that the documentation just bit too in depth I think. Good. Okay, great. Links to other use cases. I had seen that or course does kind of just avoiding it was quiet and and that was, it was a, it was an effort we launched about six or nine months ago when a new contributor came on said he had like something. I said, gee, this is one I'm interested in the contributor did it, but then I found a bunch of flaws in it. I used it for what I needed I learned what I needed but then didn't, didn't get it merged so I think this is a good one we'll just plan to repurpose it into pull request to the plugin installation manager docs, and then have hyperlinks from there from from jankins.io to the plugin installation manager docs. Great. Thanks. Thanks for that. All right, so next topic was Java end of life plan or alternatives and it's really not. This is not a plan yet. So, Tim, I think you probably want to weigh in here I've seen suggestions for things like one was declare end of life in 12 months, or another was declare end of life plus, plus extended support if the security team is willing to do that. And it's in end months or 12 is some, you know, some arbitrary number. Any, any other that you want to weigh in there on hey we should do we should consider this way or consider this way. Thanks so I mean, it'd be good to get the numbers fixed. But it looks like the numbers were a lot higher than we thought because of the broken usage stats it's assuming that it's something like 25% or more currently running on 11. But it'd be good to see those numbers properly. Right, okay. And yeah, based on the usage stats that graph that showed a drop of. Yeah, I think it was 25%. I'm assuming that that drop in reporting will will now show up when we get it corrected as hey these are Java 11 users now. Yeah, I'd expect so. All right, guide the decision. Good. Okay. So it's just more and more libraries and I mean don't like the language is the Java right it's not like something like seven years old now. Oh yeah yeah it's, it's it's well and, and, yeah, we've now got two LTS is after it right so we've got 11 and 17 both as LTS is after it. And the fact that it's so long lived is really impressive, but eventually libraries and jetty is the is the classic example right if jetty drops support we have no choice. So we've, we've got to, we just as well start the discussions. We can, we can live with stay on an older version of jkit but we really can't live stay with on unsupported version of jetty. And it's better that we start it before JD does it especially if they're doing it anyway. Right. Exactly yeah and, and Olivier's comment was it may be a year or two before they drop support but we want to be ahead of them in ending end of life. Yeah, yeah exactly. So a thought I had was declare end of life in some number of months or declare end of life plus extended support or declare end of life when use counts reach some threshold. And that one for me is a little less attractive because it makes it unclear for users, but we could, we could say hey we'll, we'll start the process when we hit 75% or something like that or 25% of installs or something like that. I think we need to worry too much about numbers. It's more for the developers and security. Like the numbers are high enough already. I think. Good. Okay, thanks. It's not like when the last one of the last times came up people like only 800 instances using it at that point zero zero zero percent. We need to fix the adoption but so, but it turns out it turns out it wasn't like that but things like the admin monitor probably boosted a lot. So I think we've got, we've got every reason and the admin monitor first became visible to LTS in 2.303 so so we're only one LTS cycle into having that admin monitor but we're at least one in and we're already seeing good, good motion or what we think is good motion towards Java 11. Now my assumption is we would, we would use a Jenkins enhancement proposal, similar to what we did with with the Docker image change, propose, propose the process, etc. And I don't know when that will work. I've got from a commercial side I've got to be sure that I've discussed with people inside my employer to assure that that this represents their concerns as well. I've started those discussions. They haven't support Java 11 yet. They are, they are actively in progress. So, so, so yes that's the nerve wracking part right is, but there's lots of interest to yes let's let's proceed. I guess another piece of this is, dude, does this need to be connected to to Java 17 in any way and my, my thought was no it doesn't, it's really independent Java 17 is a separate conversation. But we probably want a separate conversation in the next contributor summit about Java 17. Yes, it's kind of a point in his lap. Well, why if you're going to jump one kind of could just jump straight to 17. Yeah, although for me that one is, I haven't seen enough. Yeah, I definitely haven't well, I haven't seen enough adoption yet of 17 to say that. And is your sense have you had a lot of bug reports from the preview preview that you provided for Java 17 on Docker. It's not very many people using it, but a couple of people have tried it out. Okay. Great. I that's all that I had on Java eight end of life. I think we ought to just carry it as a as an ongoing topic here, I sure we discuss it and we'll continue in the mailing list. Okay with you Tim. Okay, great. So, I had multi platform support blog post I want to highlight that we've got AMD 64 arm and system 390. As far as I understand it we don't have power PC support because the QM QM you fixed that we need it is not yet implemented is that consistent for you. Haven't tried in a few months but the bug report still open. Okay, all right. I'm going to try it again you just have to enable on the poor quest does full validation on the poor quest to make sure it works. Okay. That's, it's pretty trivial to test it and spend a few versions since but yeah. There was a couple of comments on the bug report about rooting at places but nothing saying it was fixed. Okay, super. I don't have any objections if I create that blog post. It's major portion of your work. I'm just going to be describing it. All right. Okay. Java version update automation so this was when I needed a conversation with you I think actually in terms of. We've enabled depend about on the Docker the base Docker images but I'm not sure that they're always consistently detecting new changes to Docker images do you have experience there that you can guide on. Hey, let's just give up on depend about and switch to update CLI or do we do we stay with depend about and see that it works. The problem with depend about is it's very zero configuration. So, problem and nice doesn't work very well with Docker. It works only if it's like simple and increasing and formats that they pass it's all that is generally they're not you they don't use the CLI tools or anything to figure things out they use pattern matching and it's all written in Ruby and they kind of extract things out and because I looked at it for seeing if we could get Jenkins version update updating working. And the other don't have any knowledge of anything outside of the file they don't run Maven or anything, at least with the Maven one. It's all just extracting versions and string matching and finding them and then checking with upstream. I think it's, I think it's just some version formats work and some don't the ubi stuff works. But I don't think anything else works. I'm a little, I'm a Linux works apparently. Okay, so that's going from like 8485. Yes, I've looked at Alpine's working on Linux is working. That DB is working apparently seems seems to be doing everything isn't it. So, I might not be doing the JDK ones. Right so and so the Docker image stuff, I think, at least I think the ones that I've enabled have shown some promise of working I've seen plenty of places where, where it's dubious to even have depend about enabled for instance I track fedora versions on a, on a test repository run for platform labeler and it's no help. Right there version numbering scheme is inadequate so in terms of. Yeah, so the Docker stuff I think is working. If we wanted to do Java, I can't see a way to do Java with depend about at least it hasn't ever offered a Java update in our in our images. It'll be the version scheme is not clear enough to it. Right. Let's say, so I assume no objections from you if somebody submits a poll request to try and propose to use update CLI or some other tool to do Java and get and and get LFS those those sort of tools internals. Yeah, no objections. I mean, ideally those most of those things will be done in the docker bake stuff anyway. The problem is that windows isn't supported there unfortunately. Oh, good point. I mean we could have like a shell script with a lot of properties file at the roots. Now possibly like a properties file at the root which just has all the versions. Thanks. Okay yeah so using because bake, bake is just a natural way we're doing those things now that makes sense. Great. It means we don't have to update 20 files, but it's also annoying is that the windows isn't supported. And have you seen any hints from the Docker, the Docker people that they're going to support windows on build X on bake. There's nothing that's not the docker they bake relies on upstream so container D is where the issue is that container D. I'm subscribed to the issue. It's in a Microsoft Reaper somewhere. So as a community contributor working on it at some points and did some PRs to container D. And Microsoft, I think Microsoft, I haven't done the work required. There was a project over program manager commenting on the thread a little bit asking what people wanted it for trying to, I guess, get enough reason to invest in it. Okay, alright so so conversations are continuing, but no no commitment there. So if we if we did it as a top level property properties file, then we would have all the Linux, all the Linux variants would be would get from a single location and all we have to maintain is the Microsoft although the one or two or three windows images. I'm sure you can make the power shell scripts read it as well it just won't be as easy. Oh, right, right okay. Power shell is a full full language basically. Right, right properties file from PowerShell. Yeah, good point. It's just, it's not as familiar a language for some of us, like me. I just, well, these days you've got pwsh and it's more cross platforms but easier, but yeah no I avoid it. Okay. All right, and then the next one is on Docker image update automation so we talked about Java this one it feels like we're doing okay. You noted that Alma Linux updates are detected I've seen Debian ones detected and I know that Alpine or was Alpine detected, I think Alpine was. Okay, so good. So we stay with stay with that and depend about for now. So it's just Java that I can say that's missing which is a bit annoying but right. All right, thanks. Any other topics that you wanted to bring to the session today Tim. No. Okay, thanks a bunch we've got an upcoming release next Wednesday or no no week from Wednesday it's not waxed and it's 10 days away right. So we've got time to create those upgrade guides. Thanks very much. Thank you. See you.