 Welcome. It's the Jenkins platform special interest group. It's the 25th of February, 2022 topics for today include open action items required Java 11 or newer for Jenkins core Linux operating system support policy. The switch from system five in it to system D in Jenkins Linux Linux packaging, and we won't cover exit lifecycle change we need to carry that one forward. We need some discussion with Basel and with Tim Jack home before we have more to talk about any other topics that need to be on today's agenda. Not that I know. All right, then let's go ahead so I still have one open action item plugin installation manager docs we have a pull request that we closed that was deep and covering but filled with a number of mistakes. The next action item we decided in docs office hours was will describe a simple use case on Jenkins on www.jankens.io and the more detailed cases in the plugin installation manager tool repository still open there that will need some work. Java 11 or newer requirement for Jenkins core that Jenkins enhancement proposal has been merged. It does not yet have a timeline. The timeline in order to determine it. We've got help from Basel Crow he'll be doing some more detailed checks and looking for problems or issues that might be might be getting in our way. Tim Jacob asked if we could fit that into an upcoming weekly very soon with the intent that we would release it in June, and I've asked for an additional two weeks to do deeper evaluation. So we're tracking the details in this JIRA epic. The JIRA epic right now has five items in it. One of those items Jesse Glick specifically expressed his worry about that it could be a blocker for people upgrading to use Java 11 on their controller. Others, I'm less concerned about work that must be done but he's worried that this one is a real blocker as a bug. So the one you're pointing at correct yes this 59910 this one is he's worried that this looks very serious and we haven't done enough nearly enough investigation yet to understand is it a real problem or not. Okay, so we've got still a number of candidate issues that need to be reviewed. There's a list of 37 that are good candidates that need to be assessed some of them are specific to plugins etc so they're not all yes we must fix them but there are some that that have that need to be looked at. And that's, then there's some old ones in this epic that we had where this epic mostly contains things that are resolved because it was used for two years ago when we did Java 11. But there's still some that aren't resolved here that may need to be considered need thought. Any questions there on the Java 11 or newer approach. No. Okay, let's work ahead. And there is a lot of work ahead on that one absolutely. Next was a Linux operating system support policy. We have had for a year or more a windows support policy because we needed a way to express which windows versions we were testing in which we were not. This Linux support policy started with that idea and then Basel stepped in and said hey you know what we should describe this more accurately based on what we actually test. We have since added many, many tests of the installers from many different Linux operating systems. And so there is still work to be done on this pull request in terms of assuring that people agree with it but for me I think it's very close to describing what it should we've got three levels of support. We support a platform if we run automated tests on it. We put it at level two patches considered if we don't run automated tests on it. And unsupported is if the vendor does not support it we refuse to support it as well. Okay, make sense. Then the next hot topic is switching Linux packages from system five in it to system D. And then we have a change to the internals of the Linux installers RPM Deb RPM for both Susie and for for red hat, and it's been proposed to include in Jenkins 2.332 dot one LTS March nine discussion is happening in the mailing list now. And we'll see if we don't choose to include this and we have a little bit of work we need to do in the packaging repository to get it back to behave like it did in two dot three nineteen dot three. Probably trying to smash an open door. The upgrade parts so people that have an existing installation using the old methods or have rests of that, if they apply the new installer, or I don't know how to express it but they take a newer generation of installer. It will not break. So what what Basel did is he created an upgrade path that takes their existing settings and brings them into system D, and it now makes it actually quite a bit easier to edit settings whereas before, I had to have platform specific descriptions of in order to edit settings on red hat I do this or in order to edit settings on Debbie and I do this other thing that's different. Well now in there in there. Use a single command system CTL edit Jenkins to to adjust settings. It's really very very elegant and system D has some some capabilities that are just very attractive no more use of separate scripts to manage the start and stop of Jenkins system D does it directly. You will automatically restart if there's a failure so no need to do special configurations based on your operating system, in case of crashes or failures. It really is an improvement if this change fixed like 10 bugs and very nice improvement. I'm looking forward for that using a lot of Docker but. All right, that's all that I had, unless there are other topics I propose we close the session for today. Thanks john mark.