 Welcome. It's the Jenkins platform special interest group. It's the 18th of June. Remember, remember that we adhere to the Jenkins code of conduct in all of our interactions. Be nice to each other. Mike, thanks for joining. That's great. So usually what I do first is review the agenda of the meeting and see if there are any items we need to add and then we'll actually start going through the agenda so we talked to open action items. Talk about Java 11 as default in our images. Then I had a minor update on security scanning. And that's a, and then let's see coordinating proposed Docker changes. And I think that's it. Yeah, anything Mike that you wanted to add to the agenda that's not already on it. Okay. Great. So then first topics. I've got an action item to open the JEP for the Java 11 a standard Docker image and that's see the later item. And it'll be discussed at the contributor summit, June 25. So we had a concept of that we need more maintainers and we need a better process in terms of how we update our Docker images, because what we've got right now is the concept of maintainers at the repository level. And the reality is, for instance, I'm one of those maintainers but I don't look at Santos at all. And so what what this proposed JEP is is to acknowledge that we're going to use a code on our concept inside the repository, so that other people are aware, which images are maintained and which are not, and it'll have the same concept is adopt of adopt an image as we have today for adopt a plugin. Yes, I owe the team a Jenkins enhanced proposal on that one. Any question there Mike. Yeah, I think that would have been. We've got plugin installation manager documentation that's in progress could use additional people who are experts in that tool to review it. I did an initial review and it's it certainly helped me I adopted the plugin installation manager in my Docker image now thanks to that documentation, but we need others who are more expert than me to help with the reviews. We've got an open item on system 390 and on power PC, Jim Crowley of IBM he hasn't joined us for for several months so I'll need to check with Jim to see if he's still interested. New topic then Java 11. Okay, so Mike I think here the question, the question or the conversations were around. The question was, shall we drop Java 8 immediately or maintain it for a time. And my proposal is keep Java 8 because it is so widely used. What's your, what's your sense there is that are you seeing strong evidence in other places for what we should just drop out Java 8 other than the people that are currently advocating for doing that. And a lot of people asking sort of the flip side of that which is why, why Java 8 at all. And when can we start using Java 11 language features. So I think we pretty much have to, since it hasn't been formally announced, I think, just based on my gut, we, you know, we should announce our intention to do that. But we're going to have to give it, you know, six months probably I would guess lead time before it becomes an actual reality. Good. Okay, that makes sense. So if we declare if we were to choose to drop Java 8 support we would need some some nice long period to alert the users that pay Java 8 support is going away. And then to move to Java 11. Here's the plan. And it's nice that there's now the next LTS I guess there'll be a admin monitor. I guess it's already in the week, please. Yeah, that's correct so the but a lot of people like in my experience. It's more on the proprietary side but a lot of people don't update their Jenkins as frequently as we might like. So they may not see that monitor. Also they wouldn't be affected by dropping Java 8 support if they haven't updated. I guess it's an important thing to consider. The biggest impact is going to be on people who do you try to you stay relatively current. Yes, very good. Okay, excellent. So now you had suggested in your list that we communicate a plan to address the Java 11 issues. What I phrased it slightly differently that there are a number of Java 11 things that I'm not sure if they even are issues still I've seen. I still have one case of an at least one of an illegal access warning. It is just a warning. It'll be a hard error in Java 17. But are you aware of other other things. A query for current outstanding issues but I have not had a chance to really give that any sort of review. Like one like we probably do need to go through, you know, and collect as many of the open issues that we can find, and then just do a determination of how impactful they are. My field legal access warning isn't a showstopper, but I also know there's a lot of push to go to Java 17. At least in a soft way. And then a couple of months. But really just having, you know, knowing what we potentially are facing and having a plan to address anything that looks like it's going to really be a problem. Sort of seems to be prerequisite to really saying this is supported. We're not going to drop Java 8 anymore. We're saying that, you know, we will, we're going to drop Java 8. We know there's two open issues that potentially could impact a lot of people. So the plan is, will we resolve those issues, you know, in the next two months, and then in month four, we drop to drop Java 8 support or whatever the timelines and the numbers may be really just to try to move things forward. And just identify them determine which ones are a requirement to be able to drop Java 8 and have a plan to to achieve that. Right. Very good. Okay. Okay, so, so this feels like a really good place Dave and Aditya thank you both of you for joining. Great, great to have you here. So we're right now talking to Java 11 as default in our images. And the thought then was that. We would like to target September as announcement point now there's, there's there's probably here I mean we should probably outline a communication plan and delivery schedule right because one of the concerns that I appreciated, Daniel Beck was, Hey, this should happen on the edge of the LTS release so the next LTS dot one would be the first Jenkins, the first Java 11. I would give a very specific example in the Jenkins slash Jenkins colon LTS image, and we would need blog posts blog posts announcing it upgrade guide entry in the next LTS dot one upgrade guide. Are there other things we need to do in terms of communication oh social media. So communication in general is the key just to announce it far and wide and repeatedly. So nobody is caught by surprise. Right. Okay, good people people will always be caught by surprise I guess for this few people as possible. Now, and certainly there's a for me there's a concern about the, the testing that we need to do to or the review of open issues, and that we need reviewers, right we need people who can spend the time, and I assume we can ask for that help, and list that help at the contributor summit and before, because much of it is interactive checks to be sure that those issues. Right now there are, it looks like 19 of them, and 18 of the 19 are are open and not in progress so it looks like many of those are plugin specific. Good. Okay, so that's gives us some hope. And I think it's a good opportunity to get the contributor summit to socialize that list, and hopefully find some excited people who feel the way we do. can help with resolving all those or assessing them and resolving the ones that are critical at least. Yeah, because, for instance, some of these may be against relatively lower, lower priority, for example this rvm plugin. We've got a solution for that we're just going to stop delivering that plugin. That's there's no intention to ever fix that Ruby the Ruby runtime is going away. So, review the open issues we got that a communication plan. And I guess that should be part of the the JEP as well because certainly we need to be sure people understand what the plan is terms of getting the word out. Okay. Mark included. All right and then the actual code changes. And and upgrade guide info collection on what changes as a result, because one of the other changes that's hiding in this. I guess I should make that very clear. We will switch from Debian. We hope anyway to switch from Debian stretch or Buster. So that's nine. The base image 10 to Debian bullseye with the idea that they the bullseye development team has stated their plan to release in 2021 and we assume that September is is probably in time for them to have completed their release. Would that happen, regardless of the job. Yeah, it would. It's just healthy to do it at the same time, because then we're doing, we're doing multiple changes at once. The last time we updated upgraded the base OS. We used blog, we communicated with blog posts. We included in an upgrade guide. I was impressed. It did not cause an awful lot of pain as far as I could tell I don't remember receiving a single bug report or outraged complaint that we had broken someone when we upgraded from stretch to Buster on the controller. I mean, we just, we just need to be sure we do that again. Any other points Mike that you wanted to be sure we know there that to be included. I think our, I mean, I'm not super familiar with it, but I believe the CI, the OSS CI infrastructure is already doing a fairly comprehensive set of tests that should cover dropping Java support. I don't think I can't think of anything offhand that we need to add on the CI side, as far as the building testing process to ensure we're covering all of our bases. But actually good point there is, I think there's a, I don't think we're doing any windows based Docker testing, maybe missing at the moment, that's a that's a good thing to check just to see. I don't remember for sure if we do, if we have any windows based Docker images or image testing. We certainly got plenty of testing available for Java and Java 11 to be sure they both run. Okay, doors. Aditya. Any, any items that come to mind for you or Dave for you in terms of Java 11. I'm here to learn and observe. No problem. Thank you. Thanks very much for joining us. All right, then Mike I think that covers, unless you've got something else on the Java 11 topic I'd say we call it cover. Yeah, I think that's good. I can't think of anything else offhand. I just wanted to make a plan to meet, plan to meet at the contributor summit in the, in the Java 11 track and plan to continue conversations, continue conversations in the mailing list, forgive the cough. Thank you. All right, next topic was on security scanning. In FYI we've got an ongoing project with the Linux Foundation security team and the SNCC development team of seeking ways to better use the LFX security scanning facilities and teach them more about Jenkins plug-in packaging. So we've got the results of their scans, but the results of their scans are filled with unnecessary false positives because that Maven or the Jenkins HPI format does something with dependencies that SNCC isn't isn't aware of and therefore leads to to flawed flawed reports. I think is working with LFX security and sneak to try to get a better result for us. We are delighted that they scan the thousand or 2000 repositories but we can't effectively use that until we get better support for Jenkins and the Jenkins HPI format. Any questions there on security scanning. Another is code QL is is being used. It's a domain specific language available on GitHub, and Daniel Beck wrote a number of checks that are specific to Jenkins common Jenkins issues, and it's been used now to scan for hosting requests, and it's being used by a select group of plugins. And we're looking forward to further deployment in the future. So we've got some changes proposed for Docker packaging and Docker Docker building, and right now they're largely stalled so I'm not going to take much time any time here to talk just be aware that they're proposed changes to the controller, including replace install plugins as contents with the plugin installation manager Alex Earl has created this pull request, the plugin installation manager is a Java tool that is much better suited to managing plugin dependencies and plug in version numbers. His, his script change is here and pretty simple in terms of what it does it replaces the script with a call to a Java program. What we have is detailed compatibility checks to to confirm all the many ways that install plugins that sh is used, and we don't have yet have the merged pull request for this plugin installation manager documentation. Any questions there. Then, that's all I had for today's session any other topics that needed to be brought to today's session. I don't have anything Java lovers by my big concern at the moment so let's let's take our time then today and Monday, Monday and Tuesday of next week and continue to Java 11 discussions offline. We'll meet everybody on Friday next in the contributor summit for more discussion of Java 11. Thanks everybody recording will be available probably in one to two hours, so that others can see what was discussed here today. Thanks very much. Thanks Mark. Thanks Mark.