 Hi, everybody. Welcome for this new Jenkins inframitting. Today, to the agenda, we don't have many different topics. We just did the new weekly release of the version 2.280. I think everything went well. At least I did not see anybody complaining about that release yet. Just the thing that I want to highlight here is the weekly release. Yesterday, I was correctly notified when we had issues during the LTS release. I think that was LTS release. So that's realized that we can now detect if the release process was interrupted for some reason. The next topic, I think it's Mark, who brings this to the agenda, which is the fact that Microsoft won't officially support Azure plugin around 2024. From my point of view, it won't be a big deal, because the long-term goals is to rely on Kubernetes anyway. So we won't be using Azure container instances anyway. To me, that date seems quite far compared to today. I'm not worried about that. It doesn't change anything anyway. The last year, they've only been doing emergency fixes. Yeah, and it's not like nobody else can modify that code. So if, for instance, you compare that to Amazon, do not officially support the EC2 plugin, for instance. It's maintained by the community. So yeah, from my point of view, I'm not worried about that. But yeah, the main topic that I want to discuss today is about the CA certificate used to sign the update center. So, yeah. Before you go on from that one, I'm still nervous. We spent 12 months migrating JIRA. And ci.jenkins.io is a lot more complicated than JIRA. I don't think we need to do anything dramatically different, but I think we should remind ourselves that Azure is probably not, Azure in particular, ACI, is not our long-term destination. We really do, just as you said, long-term want to be on Kubernetes, and we want to be more portable than we are right now. So I think we're going to have to spend some effort to become more portable, and we just acknowledge we're going to keep spending that effort. So on that specific topic, Debian, who's not there right now, is looking at how to provision agent on Kubernetes. So we provision an Amazon cluster. And so we have ongoing work there. Nothing really major to report or highlight, but I mean... Super, Ben. So long as I don't want to arrive at 36 months from now and be surprised that something went wrong and we need to make a frantic move. So just planning is good enough for me. Thanks. So right now, we are planning to use Kubernetes to replace the Azure container instance. That's one of the plug-in. We could also use the same approach for the Oracle Cloud, whatever, Kubernetes-sponsored we have. We still have specific integration with Azure, but we don't have, I would say, strong requirements on the plugins. We still have some work around. So I mean, right now, they were just officially supporting those plugins, but yeah, we still have options and I'm not really concerned about those plugins anyway. I don't think they will stop working the day and date anyway. So I propose to continue to the CA certificates. So basically, inside Jenkins Core, we have a CA. So basically that CA is used by Jenkins to know if it can install. So let me explain this different way. So the update centers use a certificate to sign the package, the plugins that we want to install and that certificate is expiring. So the next time was something like one year ago, I generated a new one, but the problem is we use an old CA to sign that certificate and that old CA is expiring in April 2021, basically. So we need to now use a new CA that was introduced in Jenkins Core around April 2018. So basically, once we decide to use the new CA, it means that version older than 2.117 won't be able to download plugin from the update center. We delayed that decision several months ago because we didn't want to change that at that time, but I think it's time now to announce that. We will renew the, we will sign, we'll sign the update center using a newer CA, basically. I'm not sure if we can just send an email on the dev meeting list or if we have to send a blog post. I don't think it will impact the community because anyway, the version 2.117 is really old. So if the, I mean, for those people who are running that Jenkins version, they are not able to use the update center anyway. So any question on this? So you mentioned how old, what was the Jenkins version that will be the cutoff point? 2.117. And so the new, the new, the new root certificate, the root certificate is valid until 2028. So it gives us seven a year. Yeah. My sense is I think we should do a blog post just for deniability. That's a terrible thing to say, but that way we can point to something and say, look here it is, it was posted on the official site, but email to the dev list is the more likely thing it'll actually be read. Okay. I mean, I can send an email. I can send a blog post and that's, there is not a lot of things to say, just we are rotating the root CA and basically you shouldn't be affected by that, but yeah. Yeah, I don't know, blog post is really needed. That version is ancient. They're not gonna be able to use, so they won't be able to update plugins anyway. So it's basically impossible from the community update center anyway, because any plugin you try, the only plugins you better install are plugins with an old baseline that have no dependencies. This Jenkins core will always update to the latest version of a dependency. And if it's not using the LTS update center, which we only keep last four, it's just gonna break. It's, so it's basically impossible to be updating. So yeah, and I think I understand Tim yesterday or yesterday during Doc's office hours, we did a development exercise using a plugin and it defaulted to running 2.176 and immediately started offering plugin downloads that couldn't be used with that version. So you're right. So maybe it is pointless to talk about a blog post because it was already unworkable today. I think that's what you're saying, right? It's already unworkable today and a blog post isn't going to make it any less unworkable. So maybe we don't bother with a blog post and don't take Olivier's time writing a blog post, just the email to the dev list. Yeah. Okay, Olivier, are you okay with that? I'm persuaded by what Tim noted. Yeah, definitely, I mean, that's easy to just set the email, okay. Yeah. Okay, we don't have proposed to, is it already next week, the contributor? So yeah. It is, contributor summit is next, is 23rd, 24th and 25th. And actually we've got two voice, three voices that will be in that summit on this call that I wanted to check with. So this is a great excuse to ask some questions. Sure. Last topic, which is about the contributor summits, apparently it's next week. Right. So next Tuesday is the opening session of the contributor summit. It will be from three to five PM UTC. And in that we'll have five to seven minutes for each of the heads of special interest groups for each of the officers. So Tim, you'd have five to seven minutes on the presentation to share the progress from the last 12 months of release work and what you think should be coming. Olivier likewise, you can go less than that. Yes, seven minutes to just cover all the things that we did. I mean, it's not a lot. Well, not just all the things we did, all the things we did and the ideas you would like to propose for the coming year. And then we will organize ourselves into tracks. And one of the tracks I think is going to be securing the delivery pipeline for Jenkins components, for Jenkins plugins, et cetera. And there I think infra and release and security all should be involved in that single track. So first question, Olivier, I think you've already confirmed for me, you're willing to speak for a few minutes at the start. Tim, are you willing to speak as well as the release officer during that opening session? Yeah, yeah. Okay, then there was one more topic, which was on Google Summer of Code. And Kara, since you're here, would you be willing to speak on 2020's Google Summer of Code and on 2021's plan for Google Summer of Code? Yes. Thank you, Mark. The Google Summer of Code application as an org is wrapping up. And what we really need from you all, if you're interested is to put your names down as willing to be mentors for the different listed projects on the GSOC page. We have, I believe six of now, there are two more potential ones in the pipeline. One is almost certain to be end. So there is a bit of a choice. A lot of very interesting ones, Mark has put one forth. And there in addition are a number of really good ones on the cloud native topics, things like that. So if you are interested in being a mentor, you will not be the only mentor on any of these projects. You will always be prepared with another mentor. That is our goal. Ideally, we would even have up to three or more mentors. And this year's GSOC is requiring a reduced amount of hours from students, nearly half the hours. So it's only 175 hour projects over the 10 weeks. So that time will be divided up in different ways. And mentors will work with their students to determine what works best for the mentors and the students. But this means that students will be likely writing less code. I can't say that mentoring will be cut in half, but it will in all likelihood be quite reduced. What's required of you as a mentor, because what's required of the student is reduced. So hopefully no mentors will find the process entirely enjoyable and not onerous and not feel overwhelmed by it. We want to support you through the whole process. And I encourage you all to please volunteer as mentors. Thank you. All right, so proposal is to cancel next week's meeting in favor of contributor summit. Any objections? This sounds great. So I can start the event in the calendar. Great. That's all that I had, Olivier. Thanks. Thanks. Then I propose to stop the meeting here. There is no point to keep it for 30 minutes. So thanks for your time. And see you later. Bye-bye.