 Welcome everyone. This is the platform special interest group meeting. It's the 7th of May. Thanks for joining us. Let's look at our agenda. And then we'll work through it. So, an action items. Google summer of code. Wanted to do a core release project topic. From roadmap quick review. As 390 infrastructure progress, Dr PR status. Windows installer possibly if Alex joins us, not sure he'll be available. Then likewise for plug in install manager and then Oleg, did you want and wanted to hear from you a brief status on the agent imagery naming. Google season of docs and Google summer of code projects. Yeah, I did it because you really touch on the only for the plugin project, but we have two or three. Depending on who you ask projects, which are also in the scope of my platform seek. Great. Let's let's cover that. Actually, why don't we put. All of them. Let's move that one right up into the early, early spot there and let's put the whole put all of them. And we'll just make that one a sub bullet. Anything else we need to add to the agenda. Okay. Then let's, let's go ahead. So open action items. I have a new item that we added today. We want to switch so that our meetings in general are using the continuous delivery foundation zoom account rather than personal zoom accounts. I'll make that switch. Using the invite that I received from Oleg. I still have the Docker operating system support action item open my apologies. Still there. Oleg the open the window support policy. I think that we'll go ahead. Yeah, so we had a discussion and the developer mainly is stable if we have enough feedback to proceed. So my action item is to actually get it done. I wanted to finish with the image renaming first, but then I will definitely take a look at this story. Maybe after spending some time, this other ongoing request like images for architectures because they also need some time to spend. But yeah, after that, I believe that you are not blocked regarding window support and it's a good time to actually get it done. Because, for example, one of our full summer project would depend on this story in terms of. The train work baselines we need to support. Thank you. All right, and then we've still got the Docker build rework PR. My apologies. I have done no reviews on that in the intervening two weeks. We do have the infrastructure ready to support it, or at least we've got the infrastructure ready on Seattle Jenkins that I owe to support it. But we don't yet have the reviews necessary to get it done. Next topic Google summer of code projects. So I like how about if we just open those and let's take a look here quickly at. Let you review the ones that we would we think would fit well to put them under the umbrella of the platform sick. Yeah. So I will summarize the current state. So may force the announcements about a set of projects. We have seven projects accepted in total in our organization. Six projects target Jenkins. And there are projects which are directly related to the platform special interest group. So, for example, first project in the least custom Jenkins distribution bill service by sliding. So last time we agreed that it would be handled on the umbrella of the platform. And it's also added to the platform six road map, at least in the current state. The other projects we have is again performance improvement, which is somewhat related to platform seat because in it is just a common tool. So I am perfectly fine to have it under the umbrella of the seek or maybe just other platform. So it's something to be discussed. Then third project we have is Jenkins winter services. So Windows support is definitely within the six scope and we will be doing regular updates at the seek meetings about how is this project going. We already have some prototypes and hopefully we will be able to treat quickly that. So this is one of the projects where you will likely start coding period earlier. And by the way, if someone is interested, there will be a project meeting today. So in the chat, I will share the link. And first project which is probably related to platform seek is external fingerprint storage. So historically, all pluggable storage stories are handled under umbrella of cloud native special interest group. But firstly, this special interest group is still the amount. Secondly, pluggable storage, et cetera. You don't have to be in the cloud to get benefits from these stories. For me, it's rather part of the platform. So I would be hesitant about putting it into the scope because the scope for the seek is already bloated. So we had some discussion with Mark a week ago. So about potentially splitting the seek into two. One which would be focused on distributions and packaging and another one which would be focused on platform features or foundation features or whatever you call it for the project. But we haven't made the discussion official yet. So if anyone is interested to contribute, I think we will start with the seek made and paste once we are ready. Excellent. Yeah, that's a good one. I should have put that on the agenda. We should be sure we would. And so that's splitting the seek into two interest groups. And I liked your description of them. It was one was packaging and the other phrasing again. Yeah, packaging and distributions. The second one is foundation features core features, whatever. So core features can be a bit confusing because core features, it's not about Jenkins core. So, for example, a good plugin for me is a core feature. By plan plugins core feature. But yeah, foundation features might be a bit better name for that. I'm not sure. Yeah, I see what you're saying. Yeah, very good. And this is the next windows S3 90. No, sir. Distribution service. Dr. packaging. Yeah, I guess Java support would stay here as well. Oh, yes. Absolutely. Well, arguably it could be foundation or it could be something else but it depends on the number of contributors. The number of contributors is not high. So basically I wouldn't touch it. Good. Okay. Excellent. Thank you. Anything else on Google summer of code? I think specifically. So we have just started coming to bonding. So all the project teams will be meeting organizing channels. And once it's done, probably early next week, we have a meeting that can be set up on the web. And we have a community of different sets of projects, but we also have to have a start up video post this. The summary with links to projects. And after that, I think we will be encouraging cold students to join a sick meetings so that they can present the projects. They can I mean, why do community. Yeah, I would rather cut it next week or maybe even into weeks. Let's see. topic, need some further discussion on the mailing list, that discussion will happen. Yeah, it's not my immediate priority because, but in principle splitting six in such way would be reasonable. Just to make the agenda focus because you can take a look at this list. We have 12 topics or so. So, yeah. Right, and as we add students to it, as soon as we get to six or eight people in a meeting, we run the risk of just overrunning the ability to be effective. So I like that, good. Next topic, brief status on core release project. So we've released 2.233, 2.234 and 2.235 as Jenkins release is delivered by core release automation. 2.235 has been selected as the next LTS baseline. That means test heavily, test a lot. We've got about six weeks before the LTS is released and we need to check all sorts of things. Had an interesting when yesterday that Daniel Beck submitted a fix for on Internet Explorer 11 support for it. So there's plenty to be learned and plenty to be tested. The next thing coming for the core release project is security release and LTS release. And that's support for those. This is not an announcement of a security release. This is rather support to do security releases when needed. So right now we still need to use the previous automation infrastructure. So basically we do depend on Kiki to catch releases. Platform roadmap, I just captured this picture of the current state, Oleg, as one way of reminding where we are right now. Anything you wanted to talk to on platform roadmap as it's evolved in the last. So we have some stories which are not listed on this roadmap. For example, agent renaming is tracked in advocacy and outreach, seek me. But let's talk only about initiatives on the screenshot. So docker images for Windows, they're basically ready to be released. We had a discussion about what should be the baseline for the release last time. But in principle, we have tested them. We use the common flow for shipping releases. So we are ready to go. And I'm basically waiting for Alex to just make announcements. And after that we can consider this story as completed. And actually the same for new Windows installer. So for new Windows installer, we ship weekly releases with the new installer. But there is a tricky thing that new Windows installer actually requires new build scripts. So that's why this project has been delayed for almost one year because we do releases with new installer on the owner new base automation environment. And as things stay right now for security and LCS releases, we won't be able to ship the new Windows installer. So although the story is formally completed, the same time it's not completed. So I'm not exactly sure what should we do here. I would personally prefer to wait until it's in LCS. But yeah, hopefully there is no work to be done there except getting COVID information out of the line. And yeah, taking these two stories completed, we have local images for IBM 9, we have PowerPC and Open Genine. So I think we should prioritize these stories and try to get them over the line. So that we've been already delayed for months. So if you could spend some time on finishing them, it would be great. And there are also two other stories which we need to move to in progress. Custom Genine Distribution Service just because Sladyn will be working on that in JSOC. So it's a done deal. And another story which we probably need to move is immigration to adopt OpenGDK distributions. There is one present issue there with Alpine packages because there is no longer official OpenGDK images for Alpine. I thought that Jim had told us that there was at that they had just, oh no, maybe it isn't official yet. Maybe for high versions, not for OpenGDK. Again, I'm talking about OpenGDK. Right. If you talk about adopt OpenGDK, there are distributions for that. Oh, I see, so maybe I misunderstood. So you were talking to migration to adopt OpenGDK, but you're saying that Alpine does not have an OpenGDK image. Is that right? Did I understand? Well, OpenGDK image doesn't have Alpine. Ah, all right, inverse, thank you. But anyway, Alex Sertl has already submitted a public request for master images. We will need to do the same for agents. But I think that at least for Alpine, we should switch as soon as possible because we're already behind bug fixes. And yet for other images, we should also think about this too, right? But yeah, for me, first of all, try Alpine. For Alpine, we have less risk of breaking things because Alpine is all over the street. So there should be no significant difference between Alpine OpenGDK and the Alpine Adopt OpenGDK. Right, right, good point. Yeah, I think more, I think the OpenGDK version with Alpine was Java 16 early access. So it's not even usable right now. Ah, okay, so which really means it's gotta be adopt because we're running something right now on Alpine, but it's something not from the OpenGDK project and not from Adopt OpenGDK, okay. No, official Alpine images are based on Adopt OpenGDK right now. They are. But Adopt OpenGDK images are not supplied by Oracle or by OpenGDK team. They're supplied actually by Docker. It's somebody who currently maintains them. So yeah, these images have always been a bit behind and less maintain to the OpenGDK, but now they just stop shipping these bits and it's understandable, but we still support Java 8. We are still interested in providing Alpine images at least for agents. So yeah, I would suggest that we migrate to Adopt OpenGDK the short term. Great, okay. Any other items that you wanted to add to the list relative to the platform, to a roadmap, Oleg? I think it's quite packed already. Okay. For me, it would be rather finishing pending stories. I opened GEM and other contributors to get platform packages over the line. And after that, we can clean up the rest in the near term list. Great. All right. Speaking of platform packages, S390 and PowerPC infrastructure. So agents are connected to ci.jankins.io and they are actively used. Awesome, glad to hear that. Yeah, well, let's see. We've got agent provisioning automation is still needed. That's a, I think, Olivier told me it is puppet based automation, but it's functional as it sits today. So it's usable already and I know I'm using it and there are other others that are using it as well. Then on the Docker PR status, that's a needs review and test will, excuse me, we'll need an upgrade guide or will I, is the sense that we'll need an upgrade guide because there will likely be changes as part of that? For the experimental images, yeah, I guess. All this is just the experimental. So it does not affect your normal Docker packaging. So yeah, there'll be a little updates, I guess, to how you guys are handling your publishing of experimental. Actually, no, the experimental should actually, there's a couple additional tags but all the tags should exist, all the same tags should exist to just a couple additional ones. And so maybe what it is is a blog post to announce it and encourage and invite people to test and experiment. Yeah, it's really cool to see like Alex got the, you know, the Amazon ARM64 working. Oh, that's nice. Now we have access to all the architectures that you guys are supporting, so. Okay, so next up then there really is more reviews and merge to, merge to experimental and then eventually merge to release. Yeah. Test, eventually merge to release. Alex isn't here, so I'm gonna take the Windows installer just so that those who are here are aware of what's happening there. Core release automation is not delivering a zip file that it used to deliver. And so Alex and I had an exchange in IRC as he was looking, hey, what's the download location? So we've got some work still to do on core release automation with regard to Windows installer. Yeah, it was raised a couple of weeks ago. I believe there is a G-rated ticket for that. So originally it was done as an enhancement because there is no practical need to compress MSI's. But yeah, firstly our download site wasn't ready to that. Right now Windows basically needs manual management otherwise it's broken. And I believe that we haven't updated it for the last week through release. And yeah, it's just a minor fix but we need to apply this fix. Right, that's really, and I think you're right, there really, there isn't, the MSI is already well compressed. Zipping that thing doesn't buy us a whole lot compared to just leaving the MSI. Well, it's fine to ship both, but it's ultimately not needed. Also when you download MSI's, it gives more opportunities for tools like antivirus kernels, et cetera, to check signatures. Yeah, our MSI is in our assigned corrector, so or not. Yeah, they're assigned correctly. So it would be better to provide MSI's on our download site. Which is the default. And when I click through the download link, when I click the download link from the Jenkins download page for weeklies, for Windows, it does in fact download the MSI to my machine. So- Yeah, right, because we hard call it the link to MSI, our update site is still broken. So it doesn't supply proper link. And I had to just apply a pull request to inject a direct download link. Got it, okay. So we basically need to update the package Jenkins IO and mirror Jenkins IO to properly serve MSI's. You said package and what was the other one? Then mirrors. Yeah, basically it's the same now. So since we've synchronization to package, we just have to fix it in one place. Excellent. Okay, I'm gonna drop the plugin installation manager topic. It was when we had listed for, had for Alex two weeks ago, we'll have him discuss later. Oh, like I had put agent image renaming on, just wanted to give you a chance to share with us the current state there and the progress. Okay, do you want me to share the screen or- Oh, that would be great. I'll go to the blog post. Oh, yeah, I can certainly open the blog post as well. Let me just do that. We'll save time then. Okay. So yeah, it's a fresh book post, but actually the changes took place in mid April and why we didn't post announcements immediately is because we had ongoing discussion on how to properly name my agents for SSH. But yeah, what changed in the renamed official images which are being used by Jenkins users. So it's a very similar Jenkins agent. It's an bound agent which is used basically for connection of original P4 by TCP or via WebSocket. And there is also SSH agent image. So all these three images got new names. Also as a part of this change we streamlined deployment of Windows images. So now Windows images are deployed on the same location. That's why I said that we are ready to release to use Windows support, but we still need to announce that. But yeah, the main thing that these images are finally updated. And it was one of the most problematic areas of slave to agent renaming we had in Jenkins 2.0. It was just four years ago, but unfortunately the images were still old. They were getting some criticism because of the offensive names. So finally they renamed. We still have a lot of slave mentions across the organization. So if you want to get up query, there are something like this. I don't mention soft slave. Some of them are fixable, some of them are barely fixable, but we need to keep working on that. But too many issues have been addressed. So this name and several months ago, the name of SSH built the engines by game. So we're working on the stores. And in this blog post, I also used the opportunity to hit the incoming stories. So if you scroll down, there is also what's next section where I basically listed the platform six initiatives. Well, if it gets some contributors, it would be nice. Let's see. Yeah, I'm just using opportunity of having a crowd map and listing stories from there. Should be fine. Excellent. Now you mentioned that the windows images are now available through Docker Hub, through the usual. They've been always available. We just aligned where they are available. Because before that, I would be shipping uniax images to one location and windows images to another location. Historically, it was done because of Docker Hub auto build limitations. But now we just deployed to the same location. Uniax images are still built by Docker Hub auto build. Windows images are built by trusted CI. So basically it's Jenkins instance for shipping releases. And yeah, right now they're just under the same roof. So it doesn't matter which tool you use to ship the releases. And I believe that at some point we will switch Uniax build flows to our CI instance as well. Our actually CD instance because we need to ship these packages, but yeah, whatever. Thank you. Thanks very much. Yeah, so I hope we will have announcement for windows images maybe in one or two weeks. Great. I had put Google season of docs application submitted. If anything you want to describe their Oleg before we conclude. Yeah, I'm fine. So yeah, it's submitted. It's something that is being processed. So next week actually on Monday you will have a response from Google whether our application is accepted or not. If we accept it we will have one project where a technical writer would be working on a particular area of our documentation and what we discussed last time. If the platform seek has any ideas what could be improved there? Just go to our Google season of docs website and suggest the project there. Yeah. And if you talk about a facilitating documentation there is another incoming project, UI UX hackathon. We plan to host it in late May. And one of the stories today is user documentation and user documentation surprisingly improves installation guidance. So for example, installing it on windows and installing it in Docker, et cetera, et cetera. So if somebody is interested we could try to facilitate these stories as a part of this hack test. Official announcements for that. I plan to ship a message on Monday as well. Great. Well, and wiki transformation. So the wiki to Jenkins.io transformation will be part of that. Yes, it will. I'm not sure how much it's related to platform seek. Oh, fair. Right. Yeah. And in my case, there are a number of platform specific things that are still need to be transferred. There are things like the reverse proxy setup and some API things. There are all sorts of interesting platform specific topics that are not yet migrated. Yeah. So anyway, it's a gradual process. So again, for wider scale initiatives, we could try Google seasonal docs. Though it is one project that might be a competitive program. So it really depends on applications, on the interest of technical writers. And for UI UX, it's totally doable, but the other time frame will be quite tight. So if you want to document something, it should happen maybe next week. Any other topics we need to cover in the platform seek today. All right, Jim, anything from you? No, I think I'm good. All right, thanks everybody. We'll end this recording. We'll be archived later today. Thanks very, very much. Bye all.