 Welcome to the Jenkins platform special interest group. It's the 29th of January, 2021. Remember that we are, we abide by the Jenkins code of conduct. So be nice to each other. I'm going to share my screen and let's look at the agenda. So here's what I've got as topics for today. Open action items. Jenkins master, the Docker master branch, Docker changes that I think is probably going to be likely most of the meeting. And Jim, it's wonderful that you're here for this conversation because you're key participant there. Jet platform proposal that we may do just briefly and then contributor summit discussion. Are there other agenda items that need to be added to this list before we actually start through the agenda? All right, then let's get going. That's great. I hope Carl will join us. Jim, you are. Excellent. All right. So open action items. I had the action item to open the JEP for Docker operating system support and platform selection. The draft is there. I'd like to not spend a lot of time here today on it because I think we've got more practical things to discuss in terms of proposals. They're actively in progress, but it is available there and we can certainly look at it if there are questions about what it says. Alex Centos for adopt open JDK. You've submitted the PR. Anything you want to share there further on that? No, I just need some review. I think the last question was making sure we were pinning the version of the JDK, which I've done. So I just need a final review and then we can merge it. And as far as I can tell, that one is not a compatibility threat in terms of it should just continue working. That's great. Okay. So because my review of the earlier change, it looked good to me. I don't recall if I did. So you'd be okay if we merge that one even relatively quickly. There's nothing that needs to gate that one. Correct. Excellent. Thank you. Anyone else with objections on merging that Centos, use adopt open JDK PR, that will give us the benefit that now Alpine, Debian and Centos will all be using adopt open JDK for their JDK. Great. All right. So then I had an action item on the plug-in installation manager and I like that Alex, you'd suggest we consider a shim. The more I looked at that, the more interested I am in doing that to simplify. I think it fits within the context of upcoming Docker changes as well. Yeah. I have a PR almost ready. So I just need to do some more testing and then I can create a PR for it. Great. Excellent. Thank you. So the install plugins.sh script would then continue to exist, but would actually call the plug-in installation manager Java code rather than doing it all from a shell. Excellent. Okay. Jim, we had an item for you on parallelization and multi-art CI. Is there anything you wanted to report there? No. I actually just got done with the internal project. So now I'm paying back up my external projects. The one thing when I was really looking over it, I'll need to get with Alex to understand some more of the groovy parallelization code. I'm not a groovy expert. So I don't fully understand what you were doing in the old way that you have your ad and parallelization for a little bit. So we just need to figure out how to take the PR with some of the improvements I have and kind of merge in some of your parallelization with the groovy code. Sure. Gareth and Cara, I believe, are also at least maybe interested in that area. So Jim, don't be shy. Jim Crowley, Gareth for your info is part of IBM. Gareth is part of CloudBees. Cara is part of CloudBees. And so we're delighted to all be contributing to open source. It's a wonderful thing. Yeah. Again, I'll have to retake my PR and re-pull down master and then look at the changes needed to be made because I think it's been like a month or a couple of months at least since I last looked at it. So. Great. All right. Thank you. Anything else on the multi-arch topic there for you, Jim? No. OK, we'd set ourselves a goal to get the Doctor Master Branch working and I've made no progress on that Alex, anything you wanted to share there? I haven't made any progress either. I think I'm going to just met a PR to not do the publishing to Jenkins for eval. I can probably do that today. And then we can work on doing the publish bringing back that publish when we get Jim's stuff integrated. Great. OK. Certainly with the failing in the jobs failing now, it's not publishing to Jenkins for eval today. So a PR to stop that stage seems harmless. Yeah, good. That certainly won't do damage. All right. Next topic was proposed docker changes. So this one is as I was looking at the things that are pending in various pull requests, it feels like we've got several very interesting changes coming in our docker infrastructure and our docker environment. So Alex, your adopt open JDK change. I proposed an upgrade from stretch to Buster. Jim's got the proposal for multi-arch. And then coming, we've got this Alex, the one you noted that you're working on to replace the contents of install plug install SH with a call to plug in install manager. Those are the controller side. And then Cara has a PR open for non-route user on the agents and for docker build improvements. Some of these, for instance, the one that I'm frightened of is this stretch to Buster. They have compatibility risks. And I think the non-route user has also won Cara, right? Where it's got a compatibility risk to the user. You're muted, Cara. I'm not entirely sure of that, actually. I mean, the PR is failing now. I threw in some extra tests this morning and they're failing. So those need to be fixed. But it's really a test that needs to be fixed, actually. But I will look into the compatibility issue. My thought was that there are probably downstream users that were running the image and today it's running as root. And in the future, it won't run as root, right? The idea is stop running as root. And they're going to see that as a compatibility change and we're going to say, yes, it's intentional. We really mean it. You shouldn't run as root. So how we're handling that, I believe this handles it from a technical perspective is that we are leaving those images up. So these will be published separately. So this will be an entirely different new set. But yes, we will do messaging around why we're making this change, why we're making these available, and why we advise you not to run as root. OK, so the new images will actually use new names or new tags then. OK, got it. I had not understood that. Thanks. OK. So I guess the question to the group was is this, if it sounds like we encourage that on the agent side, is not a big threat? Because if I want the old behavior, I keep using the old tags. If I want the new behavior, I use new tags. So that's not a big, OK, great. Whereas, OK. I was going to say one thing that they won't get updates though. We need to make sure that those are marked as deprecated. Yeah. Oh, OK. So that makes sense. That's we're going to reduce our debt by stopping updates of things that we consider deprecated. So we do need to announce the deprecation of those things somehow. Yes. But what is our schedule? How do we do that? How do we announce it? What is our deprecation schedule? In the past, what we did was we would announce with a blog post. So when we, for instance, switched from Alpine 3.9 to Alpine 3.12, we just did a blog post and then made the change. And that one was actually surprisingly quiet. So I was assuming I'll do a blog post on this stretch to Buster change on this change from stretch to Buster. I'll do a blog post. I would do a blog post on that saying, hey, we're doing this change. Because the user will see yesterday they were running Jenkins slash Jenkins colon latest. And it was actually building using Debian 9. Tomorrow they run Jenkins slash Jenkins colon latest. And it's suddenly running Debian 10. And they'll be, oh, but my scripts are different. Or whatever happens inside them has changed for them. Mark, I think one of the, I think it was in my PR. And I know we had the issue, excuse me, talking about it. But the more verbose tags should help alleviate some of this pressure people having conflicts. Like if we have a verbose tag where it's latest, then we have a Debian tag. And then we have a Debian 9, or Debian stretch, whatever, dash stretch, and then a Debian dash Buster. As we know, people kind of want a more specific tag to stay more stable. That could avoid some confusion of, hey, I'm pulling down just latest, which as everyone knows, if you just pull down latest image on any repository, you're asking for some sort of unstable ability and also for some trouble. Like you don't know if they're ever going to change the latest to be a different distro or whatever. That's why more specific tags allow for that more control for our users. The only thing that I would add to that, though, is we need to let people know that we're no longer going to be building the stretch images, right? So if they're relying on stretch, then those image become deprecated. And so that needs to be made clear as well. We just need to make it clear when we deprecate things so that if people are using those, they know. And we give them an image that says, hey, if you're using Debian Stretch before, now you need to test Debian Buster or our latest, which is Debian Buster, and make sure that works in your environment. Yeah, I think the deprecation is still very important. But hopefully, if they really do care about the OS and specific version of that OS, they can have a more specific image to hold onto for a little bit until deprecation is fully gone and we stop supporting it and stop publishing altogether. Right. So Jim, it sounds like what that does that lobby that we've intentionally held off on PR 1070 waiting to get a formal announcement and et cetera. Seems like we would benefit if we also had yours in so that we could announce those two things together. And I don't think we need to combine it with the agent change. Kara, it sounds like you've got the compatibility of everything solved there. But for the controller side, does that make sense to you, Jim, and is 1034 the PR that adds the more verbose tags? Yeah, 1034 does. Alex actually started producing more verbose tags pretty similar to the exact same style that I was suggesting for Windows images, I'm pretty sure. So again, I think in that PR, I made a comment of a demonstration of what the verbose tags are and how all the tags that you guys still have, or still support right now, are still there. But the verbose tags is at more clarity for users who want a specific version. So I think it does make sense in getting that PR in and then adding the switch over. Great. All right. Alex, does that work OK for you then? It's actually not just on Jenkins for eval. The verbose tags are published on the Jenkins. Good. OK, so it's already published to the Jenkins org as an official. And it's like JDK-Windows server core dash, whatever, right? That's what the tag format is. It kind of follows the adoptium naming conventions for their images. Yeah, that's pretty much where I based it off of. I didn't include all the adoptium tags because they're kind of ridiculous for some of them. But I mean, since it's a base image, having all those tags makes it easier for upstream projects to pull in. OK. That feels OK. So it feels like we want to pair those two sort of together. So Jim, that means I'm now motivated to test PR 1034. I'm already testing 1070 myself. I'll start experimenting with yours so that we can look to do those as a combined thing. Yeah. Yeah, next coming week, I can put a little more time into it. So. OK, great. Excellent. All right, I would also like to propose that we close several PRs in or any other discussion on that question of coordinated announcement. Do we need to, Alex, do we need to include in the coordinated announcement install plugins.sh as part of that? Or is it you have either the separate? We could do it as part of it. I should be able to post the PR today. Oh, wow. OK, so at least it would be an option to consider making it separate because you feel like you're relatively close. All the test pass. So that it's that part's working. So great. All right. OK, so then the last topic on that general theme for me was there are several PRs in the controller repository. But given this path, I think we can safely close. There's one offering JDK 13, another one that's proposing Amazon Linux. And I don't intend to maintain either of those. And JDK 13 is already unmaintained by providers. So any objections, if I were to go in and actively close several of those with the explanation that, hey, we're going forward with this approach and moving towards implementing the JEP as described, hey, we're only going to support a certain number of platforms and we want to maintain or for anything we merge. Yeah, sounds good. All right. Last topic of the platform JEP, I propose we shift if there's any discussion. Let's put it late because I wanted to take contributor summit as a topic here. So there I've sent a proposal out to the Jenkins developer mailing list for this concept of a contributor summit in February 23 through 25, so about a month from now. The idea is we use this as an annual event. We've done it before and use it as an annual event to set the plan for the Jenkins project and where we're going and to coordinate with each other. One of the topics that's on my mind is platform. And what I wanted to ask here is to enlist each of your help to join this exercise and help with having platform discussions around where should Jenkins be going platform-wise and how. So the event is actually a three-day exercise. Day one, we start with a 90-minute Everyone Welcome Together. And then we have separate tracks on various topics. And I proposed a, I don't know if I've put it in yet. So I'll propose a platform track, something like this one that focuses on what the platform will schedule sessions to meet together as people interested in platform and bring proposals ready for the concluding meeting on the last day of the summit. So question here to everyone involved, are you willing to participate in the Jenkins contributor summit towards the end of February? And are there insights or suggestions you'd like to offer? I will not be able to do that. We have a work off-site type meeting. But don't hold up for me. OK. Good to know. All right, that already helps. That way I don't put your name on things, Alex, if knowing that you're absolutely not available. Mark, I should be open those days. Great, Jim. So I'll likely work in more detail with you. I like having somebody from what I call a platform vendor be able to help us think about this thing. I've got some other platform vendor type people that I want to get enlisted to assist as well. OK, awesome. Kara, Gareth, are the two of you OK and interested and willing? Yes. Yes, Mark, as you know, I'm really looking forward to the event. And I will ask Vibhav if he's available during those days. It would be great to have him in the platform. Well, in fact, I put Vibhav on as a proposal for that. So thanks very much for checking with him. And yes, for me as well. Excellent, thank you. All right, I think that covered everything on Contributor Summit. Any other questions there? Most of the work will happen outside this meeting. OK, and the last one, I'm actually prone to just drop the topic for now because I have not done any further edits to that since initially proposing it. It's there. I'm happy to discuss it here if you'd like. Jim, I suspect you're probably, you and Alex are two crucial ones to see, hey, does this make sense in the way you think about things? The idea here is let's propose to have the concept of a maintainer. And images that don't have maintainers go into the adopt this image program, somewhat like the Jenkins adopt this plug-in program. So the idea being if we don't have an owner for something, we probably shouldn't keep attempting to update it. At the moment, as an example, I feel risky with CentOS 7 because I don't work on it. Alex thankfully submitted a pull request. There are others that similarly worry me, hey, is this getting enough maintenance? Yeah, I will review it for sure. I have not done a review of it yet. Right, I will do that. All right. That that was all I wanted to spend your time with. And squander, are there other topics that you'd like to discuss here as a group? Just as an FYI, I submitted those two PRs. One for the disabling of Publish Experimental and the other one with the install plug-in shim. So they're there. I put them in the chat. Excellent, thank you. So I'm just going to embed them into the notes then. Thanks very much. So that's 10.73. Thanks, Alex. And you say the other one was, oh, 10.72. Great, OK. And it is, oh, cool. Any other topics for today? Thanks, everybody. Recording will be posted within probably two or three hours. Thanks, Mark. Thanks, all. Thanks.