 I have everybody welcome for this new Jenkins infra meeting, the first topic to the agenda, which is the state of server.com. So server.com is a mirror in our infrastructure that's been done for most of months. And last week, I think that was last week, we put it back in our infrastructure. But we still have one remaining issue with it, which is the IP. So based on the IP mirror bits, but basically geo IP, assign it to the United States, even if it's supposed to be running in Netherlands. We still have to, I mean, I asked that question to that mirror maintainer, but I have to send him another email because I think it was lost in the amount of decision we had. So, and there is, yes, Mark, you're muted. So my question was, is that the given the physical, the geographic location of that thing, it's between two US East Coast other mirrors. So the breadth of the people who are mistakenly asking for data from a from a European server is limited, but it's limited to a swath of the United States that goes from New York City out towards Pittsburgh, Pennsylvania. And, and I was just worried that I guess it's probably still okay because they're only going to Europe. It's not like this, the computer's actually sitting in China or in India. So it's okay for now I assume. So I think it's okay for now. I have a draft of a blog post to communicate about recent change on the mirror infrastructure. I haven't had the time to finish it, but yeah, it's working progress right now. And so I guess I'm hoping that we'll have more more soon to to upload those that are actually running. The next topic, I think that's Mark who put it here. So basically we had two major two releases. Yesterday we had an LTS release and today we had weekly release. Is there anything specific you want to mention here about those release? You did again. Mark, you were muted. I still see you as muted. I was really pleased with the release checklist. Thanks Tim for doing that. That thing just worked great. On that specific release, Garrett made a small Golan script to detect the latest version of Jenkins. And so right now the script that you have is a Python script that detects the latest weekly version, but do not hand over well the latest stable version. And so the thing is because it's a Python script, it also rely on Python. The thing that Garrett did was to have a small binary that we could add to the Docker image that we used to the release. And so it correctly fetched the latest stable release as well. So in this case it would be to the 263.3. We are still testing it, but I think it will simplify the release checklist at least for stable releases. I added a few little things. If you pass in latest LTS as the version identifier, it will actually pull out the latest LTS version. So it just filters them all out. Which I think is what you were describing the behavior that you wanted to do. So I put on the chat there the link to the repo. It's being built as binaries and there's a Docker image there. I'm just playing with the Docker multi-arch support to see if I can get it to actually compile inside there. So basically the way it's working is it reads the maven repository, so the metadata XML file. And so for the weekly, it's fairly easy because it's fetched for the latest release. But for the stable, it's a little bit more complicated because we have many different kind of releases. We have releases which have characters inside. And so, yeah, there are, I mean, that was not as simple to parse every release into. So Garrett did the last mile to have it working for the LTS, which is nice. So I assume Gareth will submit the pull request then. That sounds like a really positive thing. So Garrett should, I work with Gareth and I think that Garrett should open a pull request on the release repository. So Jenkins infrared slash release. And maybe, yeah, on that release to use that script instead of Python one and otherwise inside. So we have a Docker image that we call Jenkins infrared slash packaging that contain a lot of things. Basically, all the tooling needed to do the release and the packaging. So it's a quite big image like one gigabyte of this space. And so we should also put that small binary there. I'll put the link after the meeting. Cool. Cool. Yeah, I think, I think I follow. Yeah, the next steps. Next topic, which is about Docker image changing from Debian Stretch to Debian Buster. I guess it's Mark, you put that here. Yeah, sorry, I'm being vocal this time. So Debian Stretch has reached the end of its life. This that's Debian nine official end of support was July of 2020. It's now in the long term support mode. But that's the base for our default Docker images for Jenkins slash Jenkins colon LTS and for Jenkins slash Jenkins colon latest. That means we're running a version of JDK that's outdated as well. So I submitted a pull request that is going to switch from Debian nine to Debian 10. Considering the other efforts on cleaning up the Docker image that we have, should we do a short blog post on all the changes that we want to do on the Docker images? So we have usually we have this change coming from Debian. But Cara is also working with Debian to deprecate some old images and to also switch image. So we provide inbound agent with tools like Maven, Python, Ruby and son. And those rely on the default Docker image, which most of the time run as roots. And so we are currently changing that behavior to use a Jenkins user by default. So we are just adding the Jenkins user to those images. And so the idea is to replace those that we have right now. The problem is it's a breaking change because all the people who rely on those images will soon move from using the root user to the Jenkins user. So we want to we want to notify people enough in advance about that breaking change. I mean, it's not a big deal in a way that the root user will still be there if people really want to use the root user. But yeah, it is just to communicate about that kind of change. I like that. I should have thought of that. So let's coordinate this so that it's the transition happens for both of them. We can announce them together. And that's one of the things and which is regarding the inbound agent. And another one I've been thinking would be to clean up all Jenkins image that we do not recommend our user to use again. So the one that I have in mind I think is Jenkins yes, Jenkins, the blue shin image and stuff like that. I think if we are doing a blog post to notify Docker image changes maybe would be nice as well to announce some deprecation. Because last week when we generated the Docker image with Daniel, it took like one hours and we're really building a lot of Docker images for multiple scenarios, which is, I mean, which I don't think makes sense in our case. Any suggestion on this topic? At least for me that sounds great. I like that. We should plan that together. Damian, Olivier work together. Good insight. Thanks. The last topic. So no, I have two last, I have one last topic that I would like to do before we mentioned the contributor summits. So in around two weeks, in around two weeks, we'll have the first time. So we'll have a virtual booth at first time. And I'm just wondering if we should not have like some maybe short demo about how we manage infrastructure. Let's say how we deploy Jenkins in the Jenkins projects. So maybe we can prepare some demos that we would do on Saturday morning or Saturday afternoon. I mean, with whoever is interested. So we could showcase how we deploy that same thread at CI or really the CI. If people are interested to have working that with me. And so which brings me to the last topic, which is also run for them. The contributor summits. Mark, I think you wanted to bring this one. Yeah. So before we go away from the FOSTA stand, Olivier, did you want to share further on what you're envisioning there? I think that sounds like a great idea. So the demonstration, are you envisioning that live or is it playing a recording of a demo? So we won't have access to recordings. So basically what FOSTA provides us, they provide us a website available to people who visit the FOSTA. They provide us a matrix server. So we will have access to a room, which will be something like stand dash Jenkins, something like that. And so it would be nice to put a small agenda there. And we also be able to use cheat C if we want to stream any information. So I was more thinking to, let's say, yeah, do some, maybe not a workshop, but just live demo using. But if we do a live demo, would be nice to announce a schedule enough in advance. So people encourage people to attend announce demo times and themes so that people attend those times. I like that. I think it would be really, really nice to have that demo. I will be around at FOSTA. I will certainly be on the stand. And are we going to do the AMA slots with plugin maintainers? I'm not working on that. So I have, I mean, I will, personally, I have no idea. So I thought that Alyssa Tong was working that if she's not proposing to her in advocacy and outreach, because I'd be happy to be there as and ask me anything session on a particular plugin. I'm confident Tim is willing to be there as well on some other plugins. Aren't you Tim? Configuration is code. I could just ask me anything config is code. Yeah, I could try things on time, but it's harder for me with it being online, much easier if I could go there and have a whole weekend. Ah, right. Yeah, it was. Yeah. That was all that I had on my stand questions then. It feels like we've got, we've got plenty still to do. Yes. Regarding the last topic for today, which is a contributor submit. So the contributor submit is a nice moment where we can look at what we did in the Jenkins Infra project. I like, I like major changes and also discuss about what's coming for the at least six months are coming for the year. And so that's also a really good opportunity for every committee members to maybe to, to, I would say encourage to follow a specific path. So if you have any ideas, I think that's the right time. Otherwise, I'll probably start collecting stats and information for the contributor submit. Mark, do you have anything you want to add on that topic? Well, so, so in conversations with other people, I think we may have a track that would be well suited to be the combination of infrastructure security and release altogether as talking about, Hey, what does it mean to heighten the security of the process we use to release code, including plugins, etc. And so, so it's, I was thinking with Tim as release officer and Olivia you as as infrastructure officer, we may want to have some conversations with Daniel and say, All right, are there things where we might consider rather than independent tracks for release and for infra and for security, we might do a single big track, which is the combination of all those components to to improve the general security profile of the system we use to release and generate product to generate code. I'm just wondering how do you want to address that? The way I've been the way I've been hoping was that people would make comments in this this agenda document and suggest tracks that they think would work. So I'd started this security track as as an idea. And as I look at security track, I thought, Oh, it may be that we need Olivier there and we Gareth there and we need Tim there to have conversations about those topics. Okay, that was that was what I was thinking anyway. Okay, I look at those ideas. Okay. And that's that's still shaping that's really all that I had on the topic. Okay. I'll try I'll try to look at it. But yeah, definitely the contributors submit is I think really important. And in the past, we got many great feedback. So yeah, try to take the time to look at it. I'll just jump in and and say the CDF has a security SIG. So it's not FOSDM or contributor summit related but on that on that idea of security, there is this quite interesting SIG that's going on on security. And those who are involved with that with the genius project may want to start attending it. I can put the link in the next. Actually, I'll stick it here as well. What I'm wondering on this topic is should we focus on identifying gaps that we have to work in the coming years, or instead should we should we we take that opportunity like a way to do an audit of what we have? I was assuming we would it was more thinking about gaps than about audit. But audit for me was going to be a if we do an audit, for instance, the doc SIG will do an audit of doc content as prep for this summit. And then we'll discuss the results of that audit in the in the summit itself. But but my thought was that that's audit is a prep rather than an outcome of this. Okay. That's a good point. Okay. Any other suggestion? All right. Then I think we are done. Thanks for your time and see you later. Bye bye. Thanks.