 Hi, everyone. Welcome to the platform Seek meeting. This is our fifth meeting and platform special group works on several projects, including Java 11 support, multi-architecture, Docker images and Windows agents. So at this meeting, we will have a short update for each project, and we will sync up on the next actions. Just in case you're interested to get more information or join the discussion, we have a Gitter channel. Just a second, I'll share my screen. So do you see my screen? Yep. Okay, thank you. So yeah, we have Jenkins.io slash platform Seek Gitter channel. Here you can find a participant link and also link to the meeting notes from this document. So everything we will be discussing there. There we will track this Google doc and then, of course, we will publish it. So we'll try to add meeting notes there. So today we have three items in the agenda, just in a couple of old projects we have. Then I wanted to discuss regular office hours before we proceed, and I also want to discuss Google summer of code project ideas. So this is an agenda for today. And yeah, I would start with regular office hours. So my first question to you guys is whether we really need that? And if yes, how often? I was about proposing a meeting every two weeks. But yeah, maybe we want to meet more often or maybe just once per month. What would be your preference? I think two weeks is good. Yeah, same. Okay. Any other opinions? No, I agree. Two weeks is fine. Okay. Let's just set two weeks and I'll probably send a doodle link. Maybe we could just go forward with the current time. But yeah, I'm afraid it's a bit early for the West Coast. But on the other hand, other participants can join. So probably we could just keep the current time slot. Let's see what doodle says. But yeah, I believe it's something we could go forward with. Yep. And I don't know if you saw it. Oleg, but Mark joined. Hello, Mark. Hello. Excuse my being late. Sorry about that. No worries. It's 6 a.m. for you. It is. Lovely morning. Okay. I hope you got enough coffee. Okay. So next item in the agenda is the Windows installers. So Alex, if you're around, maybe you could just summarize the current status. Alex? Alex is here, but we can't hear you. Alex, if you're talking, we can't hear you. I'll mute my microphone on my laptop. Can you hear me now? Yes, we can. Okay. Sorry about that. So there are kind of two efforts that I was looking at. One was kind of updating the existing Windows installer. And the other one was chocolatey packaging. So during Jenkins World, I kind of worked with Mark a little bit to test out my initial updates of the Windows installer and receive some feedback from Mark. And there were some questions that we kind of came up with and talked about a little bit, just based on kind of the way that modern Windows works as compared to how the Windows installer was developed when it was Windows XP, basically. So there are some questions there in terms of where Jenkins Home should go on the system, because the idea would be to allow the user to specify a user account to run this service as. So do we want the Jenkins Home to go into their home directory? Or do we want it to go into a shared location? Things like that. And also, where should Jenkins Home go when you want to run Jenkins as the local system account as well? So those are just some questions. I didn't have any answers to those yet, so maybe this group can help kind of figure those out. But I have a working installer that, you know, it looks more updated than the previous one and provides some additional capabilities for setting properties of how Jenkins will run, like the user account, for instance. And it will search for a Java installation instead of using a package version, or a version that's packaged along with the installer. So there are a couple updates that I think would be really useful for people who are using this installer. Do you have a pull request for that? Because I don't see one in the Jenkins.js package. I do not have a pull request yet. I did push it to a branch or my own fork of that, and I can copy that link. Yeah, is that on the master branch? I see some patches from August and September in it. Yeah, it would be the, I think it, let me look which branch. I think it's the master branch. Yeah, and it's going to be the stuff around the 19th of September. The main changes. And really I was looking for some initial feedback before I submitted a PR. In addition, the way that the installer is built right now on the trusted infrastructure is a little bit murky. It uses things like SIGWIN and stuff like that that I think could be cleaned up significantly using Jenkins files. But I don't have enough information about what the infrastructure looks like or what's available in order to kind of push forward and create a Jenkins file. Yeah, I wish we could get Olivier on the call. He was on the call with the last SIG meeting. And maybe I can reach out to him directly about that just to kind of get some information. And then as far as chocolatey goes, there was already a chocolatey package, but it wasn't maintained by any, anyone on the actual Jenkins team. Some community member just put one together. That link, I also have a repo for that, which I just put into the chat area. Yeah, I believe I found it. Yeah, so this one, it's updated. Okay. So for that one, I actually took a lot of what that person had already done and kind of updated some things. But once the installer is updated, it would also need to change as well so that you could override some of the properties and stuff like that. So the current chocolatey package out there's actually pretty good, but it could be updated once we update the installer. Okay, so we would also need to make it a part of the default release flow if you want to make it official. I was thinking it would be pulled into that packaging repository. So I would need to incorporate it into the packaging repository. Yeah, it would be great. But even before that, maybe we could discuss having experimental packages listed on Jenkins Ion. So it actually applies to all stories we have today. So we have Jenkins Ion download. We have it on the long term and weekly. Probably we could somehow add an experimental button here and these multi-platform Docker images, Java 11 downloads, chocolatey and whatever else we have. Yeah, that'd be great. Yeah, so it would be really helpful because we create more and more such experimental images. So, right, I would have agreed. In terms of evaluating the Windows installer, would it help to have more people exploring that? I know I haven't done a Windows install with your current code since Jenkins World. So even if we don't yet have the experimental page on the download site, I may be able to give you some time to help with checking out that Windows installer. And I know I'm going to want to do some experimenting with chocolatey shortly. Yeah, I mean, the more people who look at it and throw poke holes at it, the better. I want the flow for now until we have CI CD for that. Yeah, I would definitely not want to like just, I mean, hopefully you trust me, Mark, but having a package that's built on the infrastructure I think is key so that people kind of trust it more. Okay, so what you're saying is it really, I don't mind using a package that you haven't built on the infrastructure, but I think you're right, the trusted CI is the place before we would publish it to experimental. Right, yes. Is there some signature system or something with Scolati? Sorry, I've not used Windows for three years or so. So with the Windows installer, yes, that's why we need to build it on the trusted infrastructure because there's a signing key and so forth that is used. And that's part of the stuff that I don't know a ton about how it's set up. But yes, we definitely want to sign the Windows installer so that people can verify that it's from the correct source and so forth. Plus, the Windows infrastructure itself or installer requires signing in certain circumstances. So we definitely want to sign things. Okay. And about CI-CD, just a beginner's question basically, is there, I don't know how it works, but basically is there a CLI mode or something to install so that we could test out if that thing works in a remote machine during a PRB or whatever? Yes, so Windows installer does support use a command line msiexec.exe and you can pass different options to override properties. Right, very interactive. We could do some things like that, yes. But in such case, we would need a single-shot Windows machine which gives you local admin permissions so you can install a Windows service. Right. That's a good point. I think it's the case right now, but definitely that's the place where Olivier will help. Or at least he would be able to check. Yeah. So of course we have alternate way to at least prototype on external service if it saves time, but ideally when we start publishing official images, it should go through trust CI somehow. So is the action item then that Alex will work with Olivier to get access to the trusted CI instructions or the trusted CI environment? I guess there's no way you'll get access to the environment, so to the scripts. Right. Yeah, it's really complicated to get access to this instance, but yeah, reaching out to Olivier would be a good step for that. Yep. So while we keep it in chocolatey, we have always an option to set up it on another instance just to set up a distribution. But yeah, the main problem is that it's triggering of releases. So pretty much the same problem like we hit with multi-architecture docket packaging, but we could set up webhooks if needed. Yeah. So they provide an API on chocolatey that you can use to publish things. And then in the past also, if someone from the project emails the chocolatey organization, they would turn over the namespace for what you just showed. They would turn over this to the Jenkins organization if there was an official package. It would be really nice. Yeah, I believe that we need only one distribution for now, but yet turning it into something official would be a nice step for us. Right. So basically someone with project creds would need to email chocolatey and say, hey, we have an official package now that we would like to take over this, which was done by a community member. Doing it legal entity or whatever for that, because you always have issues. So I went through it for, I'm one of the maintainers of Iron Python. I went through it for that and it was mainly, I just had to show that I had commit access and administration access on the GitHub repo. So I don't think there was a legal entity requirement there. I can find out more information though. Okay. If just admin access is needed, I can send such email or maybe we could ask somebody from Jenkins Governance Board so that it has some more justification. Okay. I'll reach out to chocolatey and find out for sure what's needed. Okay. Thank you. Do we need a JEP for it, for another packaging? Or are we fine without it? JEP seems like a good idea in particular because we're taking over the, we really do want to make a transition of responsibility away from the rather ad hoc, the community-based chocolatey to something or to an individual in the community now to having the community as a whole on it. I think a JEP is a good thing. Okay. Yeah, probably we need to stop the evaluation flow for starters because we will need to document whatever we do there for infrastructure because it seems to be the biggest part of the change. Yeah, it would be nice. Alex, is that when you're willing to submit the JEP? Sure, I can do that. Do you want to say something? Okay. We have one for overall packaging system. No, we don't. The entire packaging system was created years or probably even decades before we had a JEP process. So we have no JEPs for packaging at all, I believe. So let's just check, but I believe the only packaging you have now is for Evergreen, but not for Jenkins itself. Yeah, no JEPs for packaging. My point is it was kind of, should we start trying to describe what, well, if the real commitment is not very clear, but what are the packages we kind of publish as a community or whatever? But yeah, I don't think anyone is going to want to make that official because right now we can just escape by saying, well, this was never supported, you know. I believe that we should just create JEPs for major changes we are doing forward. And if there is a tremendous interest to have hosting of Jenkins distributions that probably we created JEP to describe the process. So for example, now it would be a good question about multi-architecture docker image of next topic, but I'm not sure about other packages. Yeah, we'll discuss that for Alpine base and everything. Oh, yeah, Alpine is a big story. Okay, so do we have other extra items now? You need to add to, I need to create the JEP. And then I also need to incorporate the chocolatey packaging into the packaging repository. I'm not sure that we really need a single repository for everything unless it's something we really manage in such way. Yeah, I agree. Yes, or maybe hosting request. Maybe we need a Jenkins-packaging org. Yeah, just more organizations. Yeah, so as you wish, but for example, docker is already in the separate package, so if the code is self-consistent, I'm not sure that we need in the packaging, but whatever seems reasonable from the trusted CI flow. Okay. And everybody to test in those packaging, I believe. By the way, have you already excluded Java from it? Yes, for the Windows installer, the Java is not being packaged right now. Okay. Yeah, for this thing, probably we need the JEP, but I'm ready to incorporate it to JavaJEP if you want, or to a separate JEP. I'll do a separate JEP for that as well. So Java is not bundled anymore? Right. And I believe we agreed to also drop 32-bit support. Currently, it's 64-bit. We can create a 32-bit installer as well, but it's currently only 64-bit. Resist any temptation to restore 32-bit support? Same. I don't think we should commit. I mean, on the community side, there's limited time. Just resist. Microsoft doesn't apply any substantial love to 32-bit, let's not do that for us. So we still support it formally as a Jenkins project, but what we do, we stop providing MSI installer for that, and everybody is welcome to set up it on their own. I'm not sure what you said. We're supporting it formally, or I mean, it was the case, and this is just what's now. Yeah, it doesn't change. So everybody is still able to run 32-bit platforms. And actually, the problem for us is that, by default, the Windows installer was just broken. If you were running it on 64-bit system, you were getting a Jenkins installation, which was built at managing processes on 64-bit systems. So we just fixed 64-bit installer, I believe. 32-bit, okay, it's a breaking change, but yeah, I think we are fine with that. We'll be ready tonight. Yeah, explain why we're dropping 32-bit. It looks like a bit crazy, but yeah, it would make sense. Why? Well, I still supported 32-bit versions, especially if Windows XP embedded. I believe it will be supported till we retire, at least. Yeah, and this does not stop people from having 32-bit Windows, right? It's just the master. Okay. So yeah, I believe we have a plan for that. Or anything else? Or should we move on? I think that's all for me. Okay. Windows, are you ready? Yeah, sure. Am I audible? Yeah. So we had two approaches. One was the cross-compilation, another was native, which would happen on a particular platform using a web book. So PR 750 in the Docker repository needs to be merged so that the KMO images on the Docker Hub we can have the Docker images to be published there once a build happens. So it's important for us to get at least the PR 750 merged so that we can have the customers try out and provide their feedback with the Docker images that have been created with cross-compilation. So you do not set up the flow on external CI instance and go straight to trusted CI, right? Right. So yes, so as we discussed, right, we had two approaches. The cross-compilation option is probably more simpler, right, to go to our main repository in some time because we don't need to add any more CI nodes so that we overcome the security requirements, right, that's needed by Jenkins. So that might be one of the most safer options. If the customers say, okay, we are all good with the cross-compilation binaries, right? They are not having any issues. Then that might be one of the more easier solutions for us to vote upwards to the Jenkins official Docker Hub repository, right? That is Jenkins slash Jenkins. However, what I have done at the moment is I have also, I have also added a CI for S390X platform which would receive the notification from the Docker Hub and build the Docker images more natively for S390X and push it to the Jenkins for eval repo. So at the moment, if you look at the Jenkins for eval. Yeah, I'm looking for it. Sure. Yeah, I messed up something. Yeah, so I have pasted the link in the Hangouts. Yeah, I see that. Yeah, so if you notice here that every time there is any push that happens into the official Jenkins repository, a build will be triggered natively on the CI that has been added and it will push all those images. So at this moment, I am restricting it to around five versions since I'm just under experimental stuff, but so this is just a comparison for the customers, right? So if a customer's come, then what we could do is we could point them to this images that have been generated by two approaches. One is the cross compilation and one is native and see how it fares. At the moment, I have been verifying this internally, right? With both the approaches and I haven't faced any issues either on S390 with power or even with Alpine based images. So the cross compilation as well as a native builds Docker images are faring pretty well without any issues. So this is one of the reasons I am somehow now feeling that even if the cross compilation generated images works well, I think that might be a easier way out for us because we don't need to get into any security related discussions and so on. Because if we start adding more nodes or more platforms using the native approach, then we might need more stringent process on how we can add more architectures to hook into the CI and then how do we maintain the SLAs, right? How quickly each one can turn the turnaround time and so on. So we might get rid of that. So that's the reason I am keeping my fingers crossed on the cross compilation based images, right? At the moment, it's pretty good. No issues as such, but we need to see once we move on, right? If there are any problems that the customers face. So that's the reason we have these two approach based images being thrown out or given to the customers to try it out. However, 750 PR needs to be merged so that we can point out some of the customers or some of the users internally to use that cross-compiled based Docker images. So the only risk with this pull request is that actually it becomes a part of Jenkins Weekly release flow. So it means that it will be always running experimental. Good news is that it runs only after the main releases. So I assume it should be okay. I believe Baptiste was the last one to modify this file last week. But I believe that it should be okay. Right. So I worked with Josh on this. So we did not want it if anything fails on the experimental side. We did not want it to fail the build right because this is experimental. So that's the reason we had to explicitly return the status so that it don't fail and someone if wants to handle it then they can handle explicitly here. And the same was incorporated in the docs as well because without having this incorporated the docs would not make sense because there is no way the published experimental shell script would be invoked. Okay. So yeah, I believe that from the CI standpoint it should do the job. Obviously we need to sign off from Olivier. But for me it looks good. The main problem that we cannot really verify whether it works on Trusted CI and can we integrate that right? Right. So yeah, because we don't know exactly how the Trusted CI is configured. So when we use this with the pipeline that we just created just to test this out it works seamlessly fine. But as you know, yeah, we have a separate connection with Trusted CI around the code. So yeah, we might have to just try it out there because we don't have any way to get that tested. Yeah, one of the ways which we could probably try is to set up untrusted user on CI Jenkins IO and redirect it to Jenkins 4.0. So in addition to the production user we also have whatever test user which can deploy to Jenkins 4.0 without passing all these obstacles to get untrusted CI. Right. So again that would it help? Should be right. So at the moment doesn't the Trusted CI user have access to the Jenkins 4.0 organization in Docker Hub? I don't know, unlikely. Yeah, I think that might be the first check that you might want to do. Else it's sure short to fill it once it's merged. So I'm just writing proposal there and then I will move it to meeting nodes. My proposal would be to create another untrusted user which would be on CI Jenkins IO and which would have access to Jenkins 4.0 on there. Does it do the job? Yeah, it should. Okay. So is this within your control or we might need someone from the Infra team to help with this? We will need help with Infra team because we need to configure CI Jenkins IO. I can create user or whatever. I believe we hit the same for Java 11 already because we were unable to really test it on Trusted CI. Yeah, so there's that definitely. But I was thinking, I think the deployment and the way publishing works right now makes it pretty, as I understand it feasible to run it at any time in the week basically. So I'm not saying this is ideal, but you don't really have to, like we did, wait for the next week or whatever to have some run. So the next week is going to trigger some automated one. But if you would just merge something and want to try it before it hits the fan, basically checking if the thing you added is not breaking everything. I guess we can probably just ask Infra team to run the build and see if things still stay green or goes red or whatever and try to fix it before it actually released the week after it. Well, I wish there was at least some reporting somewhere in public space so that we can understand whether it failed or not. Yeah. We know, I mean, from someone watching that, they could wonder what the hell. But yeah, it's been, it's what's the case before. And so some of us know why it's been done this way. For privacy reasons and security reasons, many, many things were actually moved out of the public access. So yeah, that's one of the cons with that, definitely. But I guess nothing can be perfect. Yeah, right. So maybe we could work with Olivier or whatever. Well, at least putting result in GitHub command would already help us. I think at some point, possibly we could mark it right in the comments. Tyler said at some point that there's that plug-in. I don't remember the name exactly. You're not trying to have the logs or something from another instance. That might make sense to try and set up or publish some reports in the other way around possibly. But I'm not sure how anonymous and secure could be pushing those logs outside. I'm not absolutely sure. So, well, at least we could have opinion of Tyler about that and say, let's see if we could move forward. Yeah, I'll also try to get opinions about this site. Because I guess it will go good. Yeah, so I agree that we need to get opinions. Yeah, because I think we got kind of a discussion similar to this this morning basically saying the situation about that is not specific in the end to experimental bills because it's also going to be the case more and more often. Regularly with the JDK release, the cadence acceleration. So we're changing things that could break everything is going to become probably more regular. So we need to probably see how to make that more sustainable, I guess. I totally agree with that. So we have a bunch of documented changes already in the queue. So it would help us. So all ag and Baptist, right? So what is the process right now? We have been adding so many new things Java 11 and there have been there will be some more features that comes in which might need such changes. So is there any process in order to get this ruled out and tested on the trusted CI or is it that always we need to go back with the infrateam and then have them test this on their side? Yeah, because at the moment as you mentioned that we don't have any public reporting where we could get to know like how is the bill fairing on the trusted CI, right? Yeah, so right now there is no process. There is Jenkins that's in the RSC chat on free note. And yeah, the results mainly increased. But yeah, this is the only way to get information right now or whatever Gitter chat, maybe it also works. I'm not sure, but yeah, Olivier is generally in Gitter as well. I will try to get him and plus from sick. Sure. Right, and another thing which you already mentioned I think for the Windows installer and it would be I think pretty good way to have this experimental stuff that we have been doing right on the Jenkins documentation site on the download so that we have more attraction from the customers or the users right and we get to know more timely feedback and we get more and more people to test this feature out even before we go stable or include it in a weekly release. Yeah, does anybody want to take this section item for Jenkins site? If no, yeah, let's see what we can do with it. Because I don't know if you know, basically a PR on Jenkins.io which is versioned under the Jenkins-infra Gitter organization. And so it's a static site generator. So basically anyone can pretty easily add anything on the website. Yeah, I believe we can take a look because we need it for Java 11 preview availability announcement in general. So maybe we could think about it today. Okay, to get at least it. Okay, so you mentioned that it's Jenkins-infra Gitter repository, right? In order to get this in there. You mean Jenkins-io? Yeah, for the experimental stuff. For Jenkins-io, it's just Jenkins-infra Jenkins-io. Okay. Okay, so it's generally here. We need to think about the structure a bit. But yeah, you can find the download. Maybe you can download HTML Hamel. So this is how this thing is configured. So there is native packages. So there is whatever release stable. And technically we can add something like that for experimental or we can just add a link to experimental packages. So yeah, it's TBD how we do that. But yeah, it's something you can just modify this page. Okay, starting point. So I think we need to coordinate this effort because yeah, we discussed three stories today and apparently all of them need experimental packages. Yeah, so probably it's something to do. Okay, so yeah, I can take extra item for that so that we can clarify how we go forward. Okay, something like that. Any other topics for this story? I know that's it from me. Okay, so thanks a lot for the update. Yeah, I believe we're doing a good progress there. So one of the shortcuts would be to just get everything published from external infrastructure here because you already have Jenkins MultiArc Coemo where we have access but nobody published it so far. So yeah, or we just go through this flow and get everything published. Okay, Java 11, should we press it with that? Yes. Okay, let's do that. So if somebody would do... Yeah, so but it's... Yeah, okay, I'll just let it here. So let's discuss afterwards. Okay, and yeah, let's press it with Java 11. So if somebody could make notes, it would be great. I have a short slide deck. Not 90 slides as usual but really short. So Baptiste, are you going to take notes? Do you want me to take notes? I am about to do it. As we were doing before anyway, anyone feel free and encourage to just drop lines here and there so that it's easy and sharing the work in other ways. Like in Westpinsworks, kind of. Anyway, yeah, that was just in the place to do it. Okay, so then I'll just go with short update. Do you see my screen, by the way? Yeah, I believe so. Yeah, I'm still on the call. Oh, like we see your screen just great. Thank you. Okay, so Java 11 support. Actually, this is mostly a recap of slides we had at Devosworld, Jenkinsworld last month with some status updates. And actually we had a seek update in September, which is all pretty much the same status but without slides. So you can find meeting notes using this link. I pasted the link to my slide deck in meeting notes but I'll just repost it in the chat as well. Just in case somebody wants to take a look. Okay, so major changes we had since September 27th. So the first one is JEP 2011, sorry, 211. So firstly, we integrated some changes for scope of work. Before that, it was quite unclear and then caused some questions in the previous discussions. So now we explicitly have scope of changes here. We say that we do a bunch of stuff, but also we don't do some bits like Jenkins X, Evergreen, Jenkins File Runner. Also, we don't touch Gradle flow. We don't touch Windows installers because Alex is rewarding them in parallel and there is no sense to touch them. And probably the most important thing is that we agreed to exclude Alpine and Slim packaging from the scope because there is no upstream images. So it's unfortunate, but I believe that we should go without it for now and it can be edit later at any moment. So this is the scope change. We also split the plan a bit. So now there is preview availability phase. It wasn't there before. So currently if you take a look at the plan, there is a rollout plan and there are several stories. So it's already done, experimental availability from the feature branch. Now we have preview availability in weeklies, then JN week and JANLCS. So we have epics for each story and these epics more or less reflect the current state. I try to keep this epic up to date and if you guys also work on some stories, please make updates. Thank you, Baptisse, for doing that. So there is a bunch of stuff, but generally we've got a good progress. Probably I'll just proceed without starting the presentation. What is going next? Actually I would be really interested to approve this job. In August I asked for the feedback. So actually I'm still looking for feedback. So if anybody is interested, please take a look at this job and please comment in the platform segment and please if you have any comments or if you still want to review that. So I want to go forward and maybe accept it in the beginning of the next week. Does it sound reasonable? Yes. Yeah, there are still some glitches, like clean up GTK 10 mentions. I still failed to clean up everything. But yeah, so if you have any feedback, please let me know by the end of the next week, by the beginning of the next week. And yeah, Java 11 process. So currently we are here. We have all the things available for preview, but it comes from the feature branch and we need to do some changes before it becomes public. So what changed over the last months? Firstly, we had Hackfest and DevOps world conferences in both the United States and Nice. And we've got a bunch of contributors working there in order to get it over the fence. If I missed somebody, sorry about that. But yeah, generally we have some patches in documentation. We did testing, we reworked packaging. And the biggest thing is actually all functional patches already available in Jenkins Weekly. So we have integrated all changes we knew about, except the changes which were delivered with the postponed tilt like JXB bundle. And yeah, we are ready to proceed on the preview. One of the main issues we have with preview is pipeline support release to enable pipeline. So unfortunately now in order to run pipeline you need to use an incremental version of a pipeline support plugin. So if you just install vanilla Jenkins and download plugins, Jenkins won't work on Java 11 for pipeline at all. And we need to do something about that. Currently we are waiting for pipeline maintainers to provide some guidance. Yeah, I'll try to revisit this topic by the end of the next week so that we have a plan how to proceed. Then Docker packaging. So there are some good news about that. So agent's packaging is fully done. So we have all three common types of agents updated. We don't have agents for remote and call Apache Kafka, but yeah, I'll work with Wutan who is plugins maintainer to get this image out of the door as well. For masters there is Apache created by Baptiste which has been already integrated. So currently our flow in Jenkins CI Docker supports Java 11 Docker packaging. We are waiting for the release to happen. But yeah, I believe that everything should be fine there. Yeah, there's an issue here but we're working on it basically. Because of the way the published script is done it's checking for existing releases and trying to push what's missing. And because of that we've been trying since this morning to push 2, 1, 3, 2, 2, 1, 3, 3 and so on. And right now after we're launching it it's around 2, 1, 1.38 but it's stuck and Olivier would like to understand what's happening but basically I think this is just Docker Hub API crappiness issue or something. I've seen that when I was trying it out locally a few times there's a 401 that happens from time to time so I'm not sure how we're going to do that. So maybe the solution here is just to enrich the script so that a given variant could exclude a start from a given core version that would solve it for now but yeah. Good news that apparently we've got a preview release for Jenkins LCS which was quite unplanned but... Yeah, exactly. So maybe it's a good news anyway. Yeah, I'm not sure but... Yeah, absolutely. We were just planning to have the radio in the latest weekly. I hope not many people start thinking so we could maybe even delete those but start using the LTS like it's fine. Yeah, so probably we need to discuss it because our support policy explicitly says that it's in preview now but yeah. We know it, we absolutely know it won't work. The enable future Java flag isn't available. No, it will work because it builds with Java 11 patches, right? Yeah, those images actually put that flag. So what we're lying about is the version number not. Yeah, this is production experimental releases. Well, actually the recent LTS should even work so we didn't backport some patches from recent versions but you should be able to start the execution etc. Our main problem with the current deployment is that some people may think that it's a GA release. So maybe... Exactly, that's my concern indeed. Maybe you should do something about that. Yeah, I don't know exactly what yet but we need to dig into it. Should we put an action item on Bates to request it to be deleted? To request that the tag be deleted? Yeah, because... Okay, let's keep it as it is but obviously it may cause some more issue traffic. Yeah, okay. I don't know exactly what we should do here, right? Yeah, so let's take it offline because I am also not sure, but yeah. People are going to take our blabberings here as commitments, so yeah, right? Well, I would be perfectly fine if we had pipeline released by this time but yeah, our main problem is that pipeline is not available. I mean, pipeline support plugin. So these releases are going to blow up if somebody tries to migrate. That would be your usual reminder that you should be reading changelogs when you're upgrading? We have changelogs for docker packaging. Yeah, but I mean for given version. Anyway, yeah, right. Okay, so yeah, let's try to do something with it. I'm still not sure what but maybe administrative working at least which we would need to backport. Okay, so definitely something to discuss. Okay, let's go next then. Blow ocean docker images is still to do. We have experimental images with automatic deployment. So if somebody wants to try out the blow ocean, it's available on Jenkins for a while. Jenkins for a while. So blow ocean images are here. So there are tags. Yeah, probably, yeah, automatic deployment is not configured. But yeah, anyway, we need to somehow promote it to common releases with publishing like we do for the rest. So we still need to resolve that. But yeah, it's much less story than master images. Okay, CI flow. One of the good news which changed since the last version that we have Jenkins test harness integrated. So if you go here, you may see that there is pull request builder. This pull request builder, effectively it builds with JDK 11 on both Linux and Windows. So all the patches are integrated even for Jenkins test harness test flow. At least for Jenkins core. So it's a good start. And for plugins, plugin form is also updated. So all critical changes are there. There are some pitfalls like if you use PowerMock, then you will have to update on your own, which may be a problem and probably you will need some developer guidelines. But at least we are more or less good with the core. And Java 11 support integration branch currently looks like that. So we actually everything except docker file change was integrated. So branches are totally aligned, which is cool for us. It's still an open question how we deliver experimental versions after the merge. Probably we should keep Java 11 support branch for now or probably we should just integrate it and somehow get docker file builds running on commit basis. So it's open question, but generally with Jenkins test harness we are good. Except in test harness, there are pull requests from Oliver Gonza. Generally we need to think up with him and agree how we go forward. And for PCT, there is also ongoing work by Adrien and me. So we've got a pull request to enable plugin compact test that is Java 11. So it's here. It even passes the build. I still need to push some changes, but hopefully we'll start running PCT tests next week so that we get more test coverage before we announce preview and weekly releases. Speaking of, I'm not sure when we actually announce it, but I believe that once we get pipeline support over the fence and once we get test tools, probably we could announce that. So there is no other blockers. And yeah, it would be great to get it out earlier, especially taking the current state of our docker packages so that we get more testing in place and maybe more adoption. Any questions so far? Am I still online? You are. You are definitely still online and I didn't have any questions. Yeah, by the way, if somebody asks anything in the chat, I do not see it while presenting. So just raise your hand, interrupt me and ask. Okay, regarding weekly, so we still have to do a lot of testing. So for preview availability, we just prepare test frameworks and clean up known issues. Then we also have two open concerns we need to resolve before we get into GE in the weekly. So firstly, it's jugsby packaging, which we haven't addressed yet. So with the current state, when you want to run with Java 11, actually you can, but you need to download some jar libraries and then pass this command line. So out of the box experience for work files is far from being perfect. And it's something we need to consider before the weekly releases. We somehow fix that or document it, but it needs to be discussed and we need to resolve that. And Java Web Start, there is pull request from Markweight. So the story behind it, that the Java Web Start is removed from GDK 11 at all. So we need to warn our users that start agent buttons do not longer work in Java 11. So there is a pull request from Mark which should fix that. And if somebody is around, reviews will be appreciated. Because earlier we merged that, earlier we fine with it. So there is no need to postpone it before the weekly is here. The pull request built failed, but I believe it's not related. Or maybe it's related, for sure. I don't know if it's related, but definitely there are changes requested in terms of making it better for the user. I may yet today get a chance to propose one or two changes to that that will then cause the pull request to build again. Okay, it would be great. So I believe these are the only blockers. If you see more blockers, please let us know. So we have one major question is about plugins which are going to break. Because we don't know which plugins are going to break. Probably many. And we rely on the preview mode and on incoming testing to get that. So there is still a bunch of plugins which are likely to fail. For example, we know that version column plugin has issues with visualization. There is a ticket somewhere. Most likely, Jack-O-Cop plugin won't work with Java 11. I still need to run PCT because Jack-O-Cop plugin includes power mock tests. So it just fails on Java 11 out of the box until I update that. But yeah, there are problems there. And most likely we'll have other issues we haven't discovered yet. So some plugins like Monitoring were already fixed. But yeah, there is probably a long tail of plugins which are going to be impacted a bit. So if anybody is interested, you are more than welcome to run tests and provide feedback. So if we know about plugins, it's something we are going to at least review and probably prioritize before the final J. Speaking of that, yeah. I was thinking maybe we could see to publish ourselves or, well, you already did kind of. But you know, a Jenkins block entry maybe, or maybe get help from the Evangelist team to publish some things, you know, to try and document how to help basically. Yeah, so it's a plan for preview announcement. Yeah, but we could do that slightly earlier. I mean, you know, just before the preview for the potential contributors having, you know, some attention so people would try things out because many people I know are happy to try things. Anyway, so my plan was to post a preview blog post plus developer guidelines. So we definitely need that. So it would be pretty much the same format as we did for JEP 200 before. So just a second I believe it's still in my hot list or no. Yeah, so it's here. So it's an announcement blog post integrated into Jenkins code. We didn't do preview availability there. Probably we should have done that, but yeah. So there is a blog post which describes how to test it, how to approach that, how to run that and how to update plugins, etc. In order to make them compatible. So I believe it's something we need to do for the preview announcement so that we start earlier. Yep, and another side of the maintenance. So in the JEP we have post release support and actually we have Java 11 support team which is about being created. So if somebody is interested to be a part of the team just join it on GitHub. So we use this team now to do code reviews. But yeah, I believe that there will be a kind of entity for Trajan coefficients as well. So there will be maintenance team which will be doing three each of issues and we will launch this team in parallel with preview availability announcement. And another part which we are going to have, there will be a wiki page for the track known Java 11 and competibilities. Again, similarly to what we had with JEP 200. The change with Java will be a bit better for us because not everybody will hop in Java 11 immediately and we will still have downgrade to Java 8 as a resolution. But yeah, I believe the track changes like on this page is something we need to do. So the final format is to publish, but yeah, we need this page before the preview availability. So I will just add other blockers which I forgot to mention in the slide there. I believe somebody to post the preview availability block post and also support capability or this is what we need to do. Compatibility wiki page and that's it. Any other feedback about what we need to do and what is missing in the slides or in the JEP? Nope, you are still online. Okay, thank you. Okay, so yeah, I will just finish this thing and then we can press it with other topics. So post GA what we will need to do actually Java 11 maintenance as I said Java 11 support team the current JEP resumes that we maintain it at least for two months before the availability in LCS and now this docker hub thing doesn't count as this. So it's a minimum April 2018 according to the current plan 2019 and probably a bit later. So let's see how it works. Then there will be a lot of technical depth cleaned up. So there is a ticket with a bunch of tickets probably we need some pagination in Jira soon, but still there is a lot of stuff to do and we have an open question about sub-project packaging, so Jenkins Evergreen, Jenkins father-runner, Jenkins X all of them may need some packaging. So it's an open question and discussion. If you're part of the sub-projects please feel free to join the discussion and to coordinate releases with us. So far it's not a part of the JEP but obviously we will coordinate everything. And there is also early access for Java 12 which is already available and probably we need to start setting up some testing because Jenkins is a part of quality outreach and we expect to provide feedback about testing statuses. So does anybody want to contribute on this story? If yes I can describe how. If no stay tuned for the blog post because we are going to describe it anyway but generally there is running with Java 10 and 11 blog posts so you just run and provide any feedback, any issues you hit, any complexity is what we are looking for. So any feedback will be really appreciated. Of course you can test your plugins, projects and just take any improvements from the list if you want. So I believe that's it. So we are still waiting for slides from DevOps World Jinx World News to be published but you can use this slide deck and this video is also recording so it's more or less the same. If you want to see the status there is also a quick talk from me. I did it last week about Java 8 to Java 11 migration so I just listed all the obstacles we hit. So it's a pretty big slide deck with all the stuff like what we hit with libraries, packaging, development tools so if you're interested to know how we hit that and what we had to address. It's probably a good place to start so that you know more about the stories because it's active for more than six months. Okay. I believe that's it from me. So are there any questions? Oleg in earlier point in the slide there was mentioned two blockers the Jaxby and that PoRequest from me. Can you give me a hint on the semantics of blocker in this case? It means we would not allow GA into weekly until that Jenkins 52282 is resolved? Yeah I think so. So for this it's rather documentation change. So yeah I believe that we need to fix it before the weekly. Okay thank you. For Jaxby it's mostly decide what we do because so far we know that it's a blocker and there are several options on the table. So we can document that. We can say that okay that's fine we can actually fix that so we need to agree on that. But yeah let's see. So it's a blocker but please don't feel that you're on the hook to deliver that. So if you have no time etc just let us know so maybe we will be able to handle it as a part of Java 11 support team unless you plan to join Mark. So you're more than welcome to join by the way. And I would like to join the Java 11 support team to be informed. I'll contribute what I can so I would like to be part of that. So if you want to join just go to the hyperlink and you should have permissions to join. You know I can just add you. Sorry point me to which hyperlink because I suspect others who are watching this video later may want to see it. So it's here. Yeah generally just drop a mail to whatever platform seek channel and we will get you ready. Yeah in general if you're looking for the teams just open the Genkin CI org and github and then click teams and you should be able to find many many teams and the public ones and I think that one is probably public. So you should be able then to click on the recalls. I think the button is like request join or something. And so this team is public because we need it for mentions. Right that's right. Yeah so I added you. By the way I'm not sure why docket repositories have explicit membership for this team. Maybe nobody is. Yeah I added that but in read mode I think so that we could request reviews from members in that team. You should be able to request the reviews anyway. Unfortunately I don't think you can review a given team without that but I can double check but I couldn't before. I'm sure to anyway so I just for people watching I did that but only in read mode so it's just kind of a github weird trick because anyway it's an open source project so read mode doesn't make sense but it's the way you can enable people to get requested reviews basically. That's strange but we can investigate it later because I was sure that you can mention teams without being a part of the repository so that's what we do for code reviewers and if we can do it for Java 11 support it may be a problem. Let's have a look at afterwards and not take them for others for this but I agree maybe I screwed up something that's very possible. I do that. I try to keep the rhythm to do that at least twice a day screw up something. No worries if you contribute to something you screw up something it happens. Okay so I believe that's what I wanted to talk about Java 11 if there is no feedback again one of the critical things we need is to approve JEP in order to proceed so if you have any feedback please provide it us up and yeah the next is Java 11 preview so if you are lucky maybe you will be able to lend it even next week but yeah it really depends on pipeline support which is not clear when it happens and the Docker packaging and JEP Java 11 is also something we need to do. Yeah just maybe something that I commented on the chat that I think makes sense for people wanting to test we should be able hopefully to provide Docker ever a green flavor for Java 11 so that people can try it out very easily and a nice way to contribute testing basically to the Jenkins project. Yeah right so if you're interested to test that there is a guideline running Jenkins with Java 10 and Java 11. So now we have a bunch of Docker images being produced including latest GDK 11, Blue Ocean GDK 11 all of them go to Jenkins-experimental so you can try them out and once we fix the issues with official release flow Jenkins-Jankins will be also available with such labels. So Oleg can you give me a refresher what is it that required the separate Blue Ocean image is there are there special changes needed in Blue Ocean? Yeah so Blue Ocean integrates Jenkins pipeline and Blue Ocean. So the idea of this image is that you can get it running out of the box and the advantage of that is that we can package incremental release for pipeline plugins. So if you go to Java 11 you may see that in plugins.txt here we install this version so pipeline support, incrementals whatever so this can incrementals change. So the advantage for users who do not want to dig into the stuff into startup guidelines so that you just launch this image and you get everything running out of the box and that's why it's better to have Blue Ocean images now available. Thank you, thanks for the clarity and so that will eventually upgrade to Blue Ocean 1.9.0 or a well I can update it. Okay, great. So yeah I just didn't update it but yeah there is a task for making this packaging official anyway. So right now it's my personal report. Yeah it's here. Thank you. Okay, thank you too. Any other questions or comments? No. Okay, thank you. So yeah the last topic in our agenda is Google Summer of Code project ideas. So I don't have whatever information for that. So just what are our plans? Of course we are planning to participate in Google Summer of Code 2019. We are waiting for public announcements. Actually according to Martin they happened on this weekend. So we will definitely apply and in order to apply we need project ideas. So if you have anything in mind and if you're interested to mentor JSOC project just let us know. There is another chat for JSOC seek. So if somebody is interested you can just join this chat and we can discuss your project ideas. So yeah it's here. And yeah we will try to incorporate these project ideas. Right now we have something like 9 or 10 project ideas but we really need more mentors, more ideas so that JSOC becomes bigger this year. Does anyone have some interest by the way? I do. I'd like to submit some ideas but in the past have been at the wrong level so I'll look for your tutoring Oleg if I offer an idea again that doesn't fit with the JSOC techniques. Yeah right. Just for that there is office hours scheduled to Wednesday. So if somebody wants to participate and to discuss project ideas please feel free to join this meeting or maybe to just send a message. So yeah it would be really helpful. That's it regarding this topic and yeah probably at the next meeting I will ping again because yeah I have at least two project ideas but they are so far not related to platform seek. Maybe the work of Windows Service Installers is actually related to platform seek. So just to give you an idea I want to work a Windows Service wrapper so that we stop doing these crazy things about XMLs etc. and probably switch to something more standard as YAML with definition checkers and maybe only with .NET 4. So dropping support of .NET 2 is something I would like to do eventually. So yeah ideas it would be nice. Okay I believe that's it and yeah we are quite running out of time. So if there are any other topics you want to discuss let's do that and probably schedule the next meeting. Yeah I believe that all our next meetings will be 45 minutes so that we do not spend so much time on the call. What do you say? I hope that next meetings will be just 45 minutes. So this one was long because firstly we had a break for more than one month due to these janky walls and other things but yeah let's meet more often and less time on the meetings. That sounds good to me as well. Thank you. Thank you too. See you next time. Yeah I'll stop the broadcast then and thanks to everybody who is watching and if you're interested to contribute just to join our special interest group. Thanks a lot Oleg for your work. Yeah thank you too. Bye. Bye.