 Okay, we are live. Welcome to the regular platform SIG meeting. Today we have Mark Wait, Adria, and Oliver on the call. We will have several topics and agenda. One of the main topics is to discuss Java 11 general with limit readiness. So whether we press it with the nonce ones. And we also have some topics in the list. They're just sent out to my screen and show the entire list. Okay, this is my screen. Yeah, so what we have today, we have action items recovered and we have a discussion about docker hub portables, which is also related to the discussion about docker in a first launch and docker publishing close. So I've seen in the chat that the address is going to join. So maybe you can just match this topic. Okay, something like that. But yeah, I'll have a brief detail copy. Any other topics to discuss? Not from me. Okay, then let's start from there. If we have some time, we can also discuss anything else. So action items. I believe that both of us haven't submitted the jobs yet. Right, my apologies. Sometime in the next two weeks, I'll get it done. Sorry about that. Yeah, two weeks, two years, open source. No worries. Yeah, Alex to request Jenkins project owner for Jenkins chocolate package. I believe something has been done on this from, but yeah, Alex wasn't online before the meeting. Yeah, as far as I know that is done and he had reported it done, but there may be details that he needs to leave it on the list. Okay, I'll just click on Alex because I just realized that we might need some of his input for Java 11G discussion. Okay, then code signing and construct is all of you. I believe there is a thread in the million piece. Just a second, I just show. Okay, doesn't matter. That's strange. I thought that there was a new thread about code signing. Maybe I missed something. No, I don't remember a recent thread, but certainly it's still an open question. Right, we still have not resolved, as far as I know, how we're gonna do the code signing. Yeah, I believe that code signing really depends on CDF because until we have a legal entity which is open to issue signing keys, we can really press it on this topic. Oh, okay. So it's not that the code signing keys, so the code signing keys that are in use today are not being used on trusted CI. They're actually being provided by Cossack or somebody else. Yeah, they are provided by Cossack and this is one of the obstacles for automating releases on trusted CI because you have automating release of Jenkins. It's one of the projects by Olivia, but finally it also has issues with code signing which we haven't resolved yet. So yeah, I think that final implementation would be somewhere here. And I'm not sure what the current Olivia's workaround plan, because yeah, currently we cannot use code signing keys formally because code signing keys are personal ones. So yeah, of course we can deploy keys signing key on our infrastructure, which is probably a bad idea, but yeah, we don't have a plan B. Super. Okay, so any other missing action items? And from me. Yeah, I'll do this. Yeah. Yeah, Dr. Murthy asked on the agenda today. So it's here. So one of the missing action items was about switching default image to CentOS. I've just put it here. Okay. And that is being actively discussed in the mailing list. Yeah, we'll put the link right away. So if somebody wants to read it, it's here. So Baptiste started the discussion. And since Baptiste isn't on the call today, maybe we'll postpone it till the next meeting. But yeah. Okay, should we talk about the Java 11 status then? Yes. Okay. So yeah, just quick update. 2.164 was a sudden launch. Since we haven't received any new regressions for Java 11, we have received one regression for the trace plugin, but it's not new. And this plugin has a relative low number of installations. So I don't think it will be a problem of OG announcement. Yeah, I just tried to try it without looking at my keyboard because if I look at my keyboard, there is something really wrong there. I mean, some German symbols, et cetera. Okay. So where is it? It was actually in the top because it's a duplicate. And so yeah, the fact that this is the only regression we know about and we are not sure what causes that. So maybe next week when Baptiste is back, we will be able to investigate it, but I don't think it's a blocker anyway. Yeah, and I've been on Java 11 for a month or more now doing Git plugin development work on all sorts of platforms. Haven't specifically tested master on Windows, but it's been rock solid stable. I think we're ready to go general availability. So one month for Git plugin. Right. Well, the Git plugin 4.0 is not stable. The Java base or the Jenkins 164 seems stable and the Java base has been very good. Yeah, right. So in my case, I am running Java 11 since September, I believe. So I was running Java 10 and I switched to Java 11 when we had a hackathon in San Francisco. And yeah, updated to 2.164 when it was released. And yeah, also no problems for me. Okay. So yeah, just to summarize other testing, what we have acceptance this harness, I believe it's okay. Yeah, that's right. With a couple of minor regressions reported in the other doc. A few minor regressions related to Java 11. Yeah, there's this, you know, this RVM doesn't work there. Yeah, all right. JRuby stuff. That's all RVM just doesn't work at all. Yeah. Yeah, let me dig the link for document volume. Yeah, just a second. Yeah. Java 11, yeah, Java 11 document cache. Acceptance this. Yeah. What is guy? Yes, that's it. Key fix. Okay. Yeah, just put missing labels because otherwise we don't see the issue in the filters. But is the plugin itself a root cause? Yeah. Well, you know, the JRuby library, I would say, or JRuby runtime or whatever it's called. Oh yeah. I think it justifies Daniel's job for removal. It have Janky's, yeah. Yeah, we have a job for removing it. But yeah, what we really need to do is to add it to known issues. So yeah, just put it, it's known regressions then. And another one is RVM, so it's not a blocker I gave you permission, sort of. Yeah, thank you. Yeah, so then at race, it's not a blocker because of the small installation number. Yeah, but put it here so that we don't forget about it. RVM not a blocker. And the second filter was about job decelerate. Right. But yeah, But if you know, if RVM is minor, this is cosmetic. Okay. Yeah, we'll just, let's just mark as Java 11 compatibility because we needed to appear it on our compatibility dashboard. No, I won't put any other needs and regressions which we haven't listed yet. And Java is being fixed, so, and it's really nothing else I know about. So what else do we have here? We have a slope count plugin. Are we still waiting for the release there? Because yeah, I believe that Baptiste has proposed a patch. Okay, yeah, we have a Jax B as a detached plugin, so it's not a blocker. But we still need it, but it doesn't block the release. What's another, the same graceful termination? Well, it's a feature request, so I believe it's not a blocker as well. What do you think about pipeline issues? Or I believe you also hit this pipeline job after the restart because yeah, this is much of the same. Yeah, well, I don't know how the other one is involved. I can speak on the first one. It was just an idea to make sure that when we fail to deserialize, which can happen, it would somehow gracefully fail pointing users that this is an upgrade of Java version and it's expected that problems can appear. And it was only a best effort. I can't if for the users. I mean, I guess this is something we can live without. And I thought that it wasn't so much, was it more an upgrade of Java 11? I thought it was that the workflow support library, it's or the workflow support plugin depended on a new component that even in Java 8 would have the same condition, wouldn't it? Yeah, it would. Okay. It would, the way this ties to Java 11 is that we needed to bomb the component version to support Java 11. Ah, thank you. Yeah. So yeah, I'll ping Devin about these things. Okay, so something like that. I just ping him, but yeah. If it's a blocker from Devin's point of view, then yeah, we might have a problem, but I don't really think it's a blocker key. And what else do we have? So, yeah, drop this and we reviewed it. It's about tooling. It just needs categorized here. Yeah, I'm fixing everything. So Java 11. Okay, so yeah, we have an only issue with tooling products which we will need to document, but yeah, I think we also agreed that it's not a blocker at the previous meetings. And that's it, what we have in the list. So just to finish testing concept and test harness is okay. Plug in a complete testing, but he has performed runs against all the plugins we have here in the list. Just a second, yeah. These plugins, yeah. And yeah, finally, it's success almost everywhere. We just didn't update this table. So yeah, we need to update the table, but I believe that IPC is also key. And the same as all other tests we've been running. For example, Bloo Ocean 18 was also a, we've been to Java 11 and it was fine. And same for the unit test, they're also fine and they are part of our CFO. So everything is actually okay. And yet taking this status, my question to the SIG meeting is whether we are ready to present this G announcements. Yes. All of your other end? Yeah, I agree. Yeah, yeah, I agree. I also joined the party. Also, do we have on the call now? Do we have grass? Are you interested in this story? And Alex? Okay, so what I will do, I will send these status to the developer million piece. Who would be able to update and create guidance to list these non-issues? Excuse me, if it can wait until tomorrow, I'm happy to take the action item. Yeah, it can wait. Yeah, or it may, is it okay if it even waits till Saturday morning, my time? But if you can wait those, that's great. I'm happy to. Yeah, it's all. So the idea is these are the upgrade guidelines on Jenkins.io. Yeah, so other end has already created pages for it. And yeah, I believe that we need to have these guidelines updated before we merge the blog post. Yeah, I think that the blog post is rather scheduled for the next week. Okay, good. So if it's ready by, ready for sure, before start of next week, that's soon enough, great. The documentation was merged, Oleg. Yeah, right. So we are just talking about follow-up, the update and the documentation to reflect this list. Well, Adrian, if you want to be the one who updates the docs, that's fine. No, I'm fine if you, I don't own the documentation. It's just a first draft in my opinion. So totally fine with anyone else updating it. Even more, if I forgot something, even more. It's maybe even better if someone else, because I was really focused on, so I might have forgot some things. Normally not, but yeah. Yeah, speaking of that, to check agent upgrade to the commentator. Yeah, because, yeah, maybe we've had several remote in-cub updates recently, and yeah, I will just double check that everything is fine, this agent upgrades. And if not, I will also suggest a full request. I continue to be delighted with the version column plugins telling me when are my agents are out of date. Yeah. Yeah, wow. You did upgrades. Yeah, to be honest, I think you should make this recommended plugin and maybe even to make it a part of the core, but yeah. It's a separate story. Yeah, actually we can discuss it next time. Yeah, I just said it, so we do forget about it. Okay, so anything else about Java 11? Any questions? Oh yeah, since Alex is on the call, I have a question about Windows installers, and actually about installers in general. Sure, go ahead. Yeah, so the problem with installers, that what we ship now, our installers are targeted towards Java 8, and they agree to not to fix installers for Java 11j, but we'll still need to do something afterwards. So currently, we'll be just shipping docket images and work files, but not many different installers. So the question is, do we want to practice some different installers right after the release, or do we want to just postpone it until it's ready? So if we want to, we should be able to patch the existing installer for Windows, mainly because it uses the Java that is being run under to package. So I can play around with that. The one problem is the current build is not very easy to do on a non-release machine in the Jenkins infrastructure, but I can play around with packaging it with Java 11 by default, if you want, and you could have two different versions, a Java 8 and a Java 11 installer. Yeah, right. So if you just propose a patch in packaging, it means that the new packaging will be applied only to the weekly release. And if something goes wrong with the weekly release, I believe we can survive. So LTS releases a card using a talk in SEM, at least they usually card in such way. Okay, I will look at it and propose a patch in packaging to Java 11 as well. Yeah, maybe we do the mic. So if you do this patch, it would be really nice to reflect it in the Jenkins change log. We don't usually reference packaging updates, but in this case it would be really nice. Okay, I will look at that. Mm-hmm. Okay, and yeah, there are also other inspovers. So if you go to JetPackage. If you just take a look at the initial key for example, you may discover that there are some dependencies. For example, in RPM, well, it's just the quotation I guess, but it may be not. I thought that the RPM still depends on the decay, explicitly, so yeah, it's commended out here. But yeah, I thought that some starters still depend on Java 11. They'll probably investigate it this week and come up with a list, but if something is really dependent, we may also need to update it. This is fine as well. Okay, I will just check it out at the meeting, but if you agree that there is no emergency needs to fix inspovers to be Java 11 compatible, I think we can just define with it. So yeah, we'll just make note about inspovers, yeah. So should we press it to the next topics? There's one more thing with regards to Java, Java readability and the release and announcement. We already have a projected date of the next LTS, which is due 164.1, and it's supposed to be 13 of March. I mean, you can tell it by the calendar, but I don't know if you want to mention it in one of the announcements, I'll pass the date in there. Yeah, so March 13th is what we were discussing yesterday. I believe that it should be fine, so we just need to make an announcement and to say that we are going to deliver it there. Maybe with some comment that something goes really wrong, but yeah, I'm not sure what would be the opinions. Yeah, I guess it's perfectly fine to announce availability weekly soon, right? Well, it's a good excuse to announce availability in weekly and encourage people to test weekly. Why? To encourage people to test RSC, because we already have this candidate. Right, good. So something like that, so we can encourage people to try the LTSRC. Yeah, I agree. Regarding the data, I think it should be fine. One minor comment that Java 11 support team might have limited availability during these dates, but I believe we will be able to monitor at least urgent requests if they happen. And yet, although we do Java 11 general availability, we don't switch to Java 11 by default anywhere. Docket defaults state Java 8, installers still state Java 8. So yeah, I believe that even if something goes wrong, there will be no emergencies. Yeah, it should be fine. Okay, anything else about this topic? Okay, if no, I propose to switch to the docket release clause. So yeah, thanks a lot to the docketers for your patience. I think that the question is when we actually can get this integrated, right? It's the PR 750. Okay, so let's just take a look at the stage together. So what we have here, so there is a long discussion, but finally... Yeah, I think the bigger problem I think happened and the way how we interpreted the variable that all right, the way how it was supposed to work and how we interpreted, right? So we assume that those, the trusted Jenkins would solve two different organizations. And accordingly, we will be having the Docker images being built and pushed to the Docker Hub in the experimental repository. But as Bhattish pointed out there, it seems like the trusted CI will just have one environment variable that Docker Hub organization exposed. So what would happen in this case is if we merge this PR, you would never have a scenario where the Docker images will never be pushed to the Jenkins for eval repository. Because the Docker Hub organization URL, the environment variable will always be set to the official repo, right, that we give. It would never take the eval repository that we have configured. And eventually will not have the images being pushed. So I believe the main concern here about impact on the trust CI. So this pipeline is executed in trusted CI already. So once we integrate this change in the make file, so let's take a look, it's publish experimental and when it happens, so here, there is no filtering. So it means that publish experimental effectively will be invoked on the trusted CI as well. I don't think so, once I can, let me just on the last one. Yeah, right. So there is a long discussion about it. The moment what happens, the health block, right? As we are saying that the experimental block within the Jenkins file. So yeah, there is no else. It's just that. Oh, the health is actually, yeah, we don't have an health specific for the experimental stuff. But there is an outer health that distinguishes running on trusted CI and not running on trusted CI. Okay, so, okay, so, yeah, let's see. If info is not trusted, we run here. But effectively this code is a part of the trusted CI file. Exactly. Now what will happen, right? In this case is that consider that it will run the experimental stage too, okay? It will eventually, because it's in the trusted CI block, but the published experimental script, if you open that publish experimental.sh, right, file? Yeah. So yeah, I believe that it will publish experimental. The problem that it will be published in experimental from trusted CI, not from CI Jenkins.io. Correct, correct. So what would happen is it would never push it to the Jenkins for eval, but rather it will push it to the Jenkins because that is the variable that is set. Yeah, right. So yeah, my proposal would be to move this code to the CI Jenkins.io execution. So we- Move it in the ev block, right? Yeah. Okay, okay. So, so yeah, I think it would be the main outcome. Right, and I think at the same time, we might want to handle the PR case, right? We might not want the PR trigger to actually push it to the Jenkins for eval, right? We would rather want it to execute that code only if it is when it's merged, correct? Because otherwise, even for the PR that people raise, the if block would be triggered. And it will, on each and every PR, it will try to push those images to the eval repository. You might have to add another condition within the if block maybe to keep PR, right? Okay. How those images being pushed on merge to master. Just a second, let me try again. Yeah. The wrong keyboard, sorry. Okay. So, move the experimental release logic to see Jenkins IO, then add filters. So that publishing happens. Only on merge and not on PR, yeah. Okay, only on merge. Yeah, and we can be specific there that it's a master branch, for example. Yeah, perfect, yeah. Yeah, because there might be other branches. Well, it might be still reasonable, but yeah, I think that it should be fine. Right, so let me add that check, right? So we went PR and ensure that it happened when they're on master branch, yeah. Mm-hmm. But I think that sounds good. So I will make the change. And maybe then yourself, Mark, what you can have a check. Yeah. So with these changes, yeah, I believe it can be merged because it will be relatively safe for a lot of flows. Okay, yeah, yeah. So I requested the changes here. I should have some bandwifes. So if you need feedback, yeah. Sure, I'll try to work on this maybe tomorrow. Okay. And get it raised up a bit there. I'll update it. Okay, so let's try to get it integrated the next Monday then. Perfect, yeah. Okay. Thank you. Any other opinions about this topic? I think we should be good for now. Hopefully no more surprises. Yeah, let's see. I love that kind of optimism. Look at us. And no more surprises. This is software. There are guaranteed surprises. Mm-hmm. That, that, that, that. I know it's a very long running PR. We have a history there. Hopefully we are towards the final line to get it. Yeah, it would be really important to do that because everybody's interested to have this multi-platform support, but we didn't get it yet. Fantastic, it's so happy to see it, right? It's not only me. There are many more interested in this. That's nice. Yeah, right. There are many interested people. I wish there were more contributors. I mean, yeah, reviews also count as contributions, but we really need more people to get it. Yeah, so we're actually running out of time. So we have two topics about the Docker Hub auto bills and those sentos. So I believe it would be nice to have a Batista on the course for all these discussions. So if everybody agrees, we can just push it to the next meeting. If not, yeah, we can discuss it today. My next meeting. Next meeting is fine with me or I? Whatever, just because of the... Yeah, I guess that's fine with me. I mean, we can live with the latest dockers for now. Okay. So yeah, I will still try to investigate what's going on. The main problem that Docker Hub auto bills just don't work reliably because we had issues with login compatibility testers today. They were bills scheduled on the morning and they still are not prioritized. I mean, they are still in the queue. So there are some issues with Docker Hub capacity nowadays. And yeah, we should be moving to other solutions as up, I believe. Yeah, I did have this issue like before. If you remember that when we wanted to have our previous solution. We could have a hook and we could because of the hard side. So I had a hard time with Docker Hub at that moment, at that time also. I had to push my own app which could take the payload and do the proper thing. Yeah, it's understandable. Unfortunately, Docker Hub still doesn't offer good application for GitHub. And this is a big problem because the integrations don't work well. So sometimes they do, but yeah, these web hooks, there is a mess there. Yeah. Okay, quick update regarding other topics. So, yeah, GSOC update, yeah, just a few words. We have got accepted to GSOC this year. We have several projects related to platform special interest group and if somebody is interested to become a commenter or to propose his own projects, it's a right time to do that. So right now, we are guaranteed to be accepted to GSOC. We are guaranteed to have at least one student slot, hopefully more. And yeah, there is a number of project ideas. So if you're interested, just propose your ideas here or join existing ones. So it might be also about Docker packaging. For example, it might be something for Java 11 if somebody wants. So yeah, now whatever idea related to coding, you can put it here. And yeah, quick update for me, I actually moved to Windows. So yeah, since many people joined before the broadcast started, you may have heard my graphic, but yeah, effectively we are on Windows now and it means that I will have some more bandwidth for Windows related stuff. Reloading for Windows service wrapper, Windows process management library and some more Windows plugins. At least hopefully I do have some time for that. There is admirable dedication from you Oleg. My head is off to you. I would never do such a sacrifice myself. Well, you just need to take a look at the new MacBook Pro keyboard. You will change your mind after that. Yeah, I would never do that sacrifice either. Sorry. Yeah, right. So yeah, my key is, yeah, it's Windows now. Yeah, it should be fine, but let's see. Yeah, so that's it. There is no other topics. Thanks a lot to everybody for participating. So the next meeting is scheduled in two weeks. Well, yeah, I believe it's in two weeks, but maybe I, Adrian and Baptiste, we might have to miss for this meeting, although I'm not 100% sure. So it's too many. But yeah, if you miss it, I will send the heads up. All right, and I believe I'll plan to run the meeting if you have to miss it, Oleg, because I'm available in two weeks. Okay, so we keep the meeting because of this. Okay, I guess that's it. Thank you, everyone. Yeah, thank you too. And stay tuned for Java 11j. Yeah, hopefully, yeah, if you get Docker things integrated, we probably should mention it in the change look as well. Or maybe, if you're interested, maybe it makes sense to create a blog post on Jenx.io and turn on so that, hey, you can try out Jenx images for other platforms now. So if you're interested, it's something we could do for sure. Sure, yeah, can take that, yeah. Okay, thank you very much. Cool, thank you. Yeah, bye. Bye.