 Okay, it's being recorded. Hi all, welcome to the Jenkins Governance Meeting to the September 16th, and we will be discussing a few topics, including recent news, progress with board and officer election preparations, and also we plan to review the road map. So these are the topics which can be submitted, and if anything else, it will be discussed a bit later. Okay, so let's go with these news. So one of them is the recent release of new LTS baseline. So Mark Daniel, would you like to speak about that? Sure, so Jenkins 2.249.1 has released. There was some concern expressed initially about compatibility. We did Vlad Silverman and I did some deep testing of windows in various scenarios, upgrading from previous versions to current version. I've been monitoring the JIRA bug queue since then, looking for issues and problems. There are still some known issues being reported, and we've just, it's been an interesting release. So windows agents, yeah, this is basically windows services. This one is fixed. So basically nothing really bad though. Yeah, this one like some investigation. Was that windows agent one? Is that the dot net? Yes. Run time issue right now? Okay. It's the version inside the config file? Yeah. So, okay. Well, this I will need to fix it. No, I'm not sure what would be my bandwidth. But yeah, regardless of the state, it would be there. It would be great if it can actually fix it. And the port fixes dot two. Okay. And yeah, on a separate note, I know that there is a blog post staged for new features introduced in this LTS. I'm not sure. Do we want to end it? No, I'm not aware of a blog post for new features. Maybe I miss something. There was a blog post from. So Vlad and I posted a description of the testing process we used and describing the three windows scenarios we use. It's been merged and is already available. Okay. And so we have that one. There is a revision proposed to the upgrade guide to deal with two surprises and that revision to the upgrade guides. Still, that's the second one down on your list there. And it still needs a revision based on feedback from Jesse Glick, but I don't think either of those things are particularly catastrophic. Okay. Yes. Yeah, I have to revise the one for before we can merge it. It's, it definitely has to have corrections based on Jesse's feedback. Yeah. I might have missed something, but yeah, I really thought that that was a blog post request. There definitely is. And you'll see a blog post for Jenkins release. Right. Okay. This one confused me. Yeah. So yeah, but. Okay, now I get it because it was just about testing. Correct. It was purely it's purely what, what, what I realized is Vlad and I were testing is we had been through a number of scenarios that may not be documented anywhere. We thought, well, we could put it into formal documentation, but that will take longer than if we just do a blog post for now. So intentionally did a shortcut. Did the blog post so that it could be out there in case it would help someone. Okay. Yeah. Thanks for the clarification on the server that I confused. Yeah. Yeah. Yeah. I was relying on my notifications, but I wasn't really looking at what's inside. Right. Okay. Okay. And the, the, the, the release of. Yeah. You fix this for plugins. Daniel, could you please summarize it? Yeah. Um, fairly, it was a fairly routine security advisory. Um, the most popular affected plugins for the email plugins where Java just has a bad default and does not actually perform host name validation. Um, there were two issues in lotion plugin. Uh, and I would like to mention that the initial version of the security advisory had a, uh, bad description for the second one. It was the same problem, but it did not correctly identify what the problem was. So, um, we've, we've updated it. Um, we never actually had, uh, cause to update an advisory entry in the last several years. Uh, so this was a new experience and not a fun one that I would like to, uh, repeat, but yeah, so, um, yeah, exactly this one. And yeah, nothing, nothing really notable. Yes. Uh, speaking of that, are we expected as CNA authority to also propagate changes like that, uh, to whatever, uh, downstream consumers? What do you mean? So, yeah, weirdly, it's advisory with CVE. I mean, I understand that somebody picks it up including description and create entries on whatever sites listing, uh, I've submitted an update to the, uh, CVE description. Um, however, the, um, in this case, the only thing that's wrong in the CVE entry is, uh, the CWE, which is a classification for the kind of vulnerability it is. And the description itself was correct. Um, 2020. Yeah. Um, maybe it hasn't been published yet. Well, I mean the, I would expect them, and that description is correct. As I mentioned, the only thing that's wrong would be the CWE. And I've submitted an update to the database there. So, uh, I would expect anyone who consumes the CVE database to synchronize later changes as well. Great. Thanks for clarification. And on other note, so Google summer of court is officially over. Uh, we have seven projects this year and all, uh, the projects have been completely successful. So we are still working on summarizing the results on the, um, I'm not sure if you're interested, but if you're interested, you can go to the Jenkins YouTube channel and they're all done. Uh, similarly, if you go to any project that also links to videos and recordings of what was presented in the end of August. So, yeah, thanks again to all contributors, including students, applicants, mentors, or convenience and basically anyone who contributed to the projects. The first year when all projects succeed. And yeah, I believe that all projects have delivered significant changes, which are important to the community. So, um, this is quite excessive success for us. Um, yeah, obviously we should be doing it next year. So we have started retrospective. Uh, the first retrospective meetings was actually today. Uh, if anybody has any feedback, please, I'll upload that in the media, and please, so that you incorporate this feedback for the next year. Um, yeah, we have also started implementation phase for Google seasonal talks. So this year we have one 90, working on Jenkins and Kubernetes documentation. So if you're interested to know more about this project patient, Jenkins Ion, and, uh, basically the goal is to have for documentation sections for Jenkins and Kubernetes, inside our documentation so that we can highlight how to use Jenkins and how to install Jenkins, how to configure either the other recent other deployment options like arbitrators, health charts and many other things which are available in the Kubernetes ecosystem for Jenkins. Right now, basically nothing is really documented on the Jenkins IO website. So that is creating some solution pages and creating the index of for the system documentation references and providing information will be really useful for those who run Jenkins and Kubernetes. If anyone is interested, please join us. And yeah, another update that next week, we actually have DevOps wall. So this is one of the reasons why we started shifting governance meetings so that there is no overlap. And I believe that there will be a lot of community presence there and multiple Jenkins-related talks, community booths and other areas. So maybe, please, would you like to summarize what's going on there for the Jenkins community? Yeah. So we have a track that is dedicated to community talks, community slash open source. And we also have a track dedicated to CDF talks. CDF also has a keynote that is taking place on Thursday after James Governor's keynote. So Marky Jackson is part of that keynote as well. He's a speaker there. So in total, we have close to more than 50 breakout sessions. That is community related, open source related. We also have a CDF booth. So under that booth, we have the different projects. So if anybody's interested in helping out at the booth, I'm going to be on the platform pretty much all day, Tuesday to Thursday. So I'll be monitoring and monitoring speaker sessions as well as the booth. So if anybody hasn't signed up and interested in signing up for staffing the booth, please let me know and we'll get you set up. Let me see what else. And for this meeting, I'm asking for permission to get the DevOps world logo on the Jenkins.io Jumbotron. And then probably shortly, I'd like to get permission to add CDCon, which is a virtual conference that is taking place in October that is hosted by CDF as well. And there are Jenkins and Jenkins X and a lot of the projects sessions are on that event. What else can I give? So for DevOps world, we are close to 20,000 registrants. And let me see. I think that's pretty much it. Unless anybody has questions for me. No, thanks for summarizing it. So I guess we need to form a revolt on Jumbotron. Well, at least since we had the governance meeting, why not? Plus one for me. Plus one for me. Sure. Thank you. Daniel, any concern? No. Okay. Yeah. Also, if you create the Jumbotron, Alisa, it makes sense to actually add the event to the calendar. Because right now you can see that there is no calendar section listed. It's because there is no incoming events in the database. Okay. So if you create Jumbotron, it would be nice to also create an event, maybe even put it into the calendar to show whether it will generate any additional traffic. But listing events could be important because we listed here, we listed on the block pages, et cetera. So it will improve visibility. Okay. All right. I'll do that. I guess the same applies to CDE. So the CDEcon. Yes. Okay. Anything else about DevOps world? Oh, on CDEcon, there was actually a blog posted on Jenkins.io for CDEcon. So that blog has already been posted. It was posted last week. Mm-hmm. There it is. Great. Yeah, right. Yeah. So this blog post basically summarizes the incoming sessions. And yeah, there are three sessions about Jenkins. Two, just one about JCASC by William. Another one about Tecton client. So this is what we were discussing with Cloud Native Seek. We've been trying to organize a meeting to succeed, but maybe we'll do one after CDEcon. And yeah, there was this talk, but I'm not sure what this is about and it's not listed. Okay. So for CDEcon, there anything else we can do? No. I think as we, as once we pass DevOps world, then we probably want to change out the Jumbotron to, like I said, to the CDEcon, to help promote the CDEcon. I think right now, we're probably at 100 registrants for CDEcon. And then hopefully by that time we should have a little bit more blogs that we can post as well. Not that we have multiple Jumbotrons. For example, we have four now published. JSOC one will be removed is my poor request, which has been already submitted. Regarding me, the continuous delivery foundation, I believe that we can safely remove it as well. It has been on for more than one year. Yeah. We could actually put both conference announcements. Oh, perfect. Okay. Jenkins is a way and dissipate and contribute. But yeah, I don't see a problem with having a CD foundation Jumbotron replaced by the conference announcement. Okay. Great. It's even better. So. More on. So it's October 08, 09. Yeah. And yesterday there was a talk meeting for CDF and there was a discussion about how to increase community engagement. And the discussion having some liking talks with demos by project participants, maybe also informal or basically just a bit of a feature focused on projects is subject to discussions. And yeah, there might be additional community content added. Okay. Should we move on to elections or do we miss any other news? I'm good. Okay. So for elections, as we discussed in August, if we want to hit the target date, beginning of December announcement for new officer assignments and elected board members, we need to hold elections in November. And although it looks like we have a lot of time, actually we don't. If you take the existing process. So there is a manual list and there is a Google doc with suggestions based on the retrospective. So this is what we discussed in the last governance meeting. And I tried to address other comments submitted by both members and other contributors. And I think that we really need to start finalizing this process so that we can make a decision firstly whether we make a change being compared to the previous year. And if we make a change, we will need to roll out it quicker. We can commit some time this week and next week to better done. But we need to agree in principle whether we change the process. And I seek feedback, especially from Alex, from Daniel, from Alisa. So Alisa, Mark and Daniel will be up for the election if you decide to participate. Me and Alex, yeah, basically we remain for another year. So that's why we, together usually are basically minus the process. So getting back from other officers and work members would be still crucial to get it done right. And I think the new proposal is sufficient and I think we should go with the change. I've read through it. I don't see any major gaps or problems. The place that I raised the one question, Oleg, you had addressed. So it was about GitHub, user ID being part of the form that we asked them to submit. Yes, so just to summarize what changes, key change is that we do not want to rely on Jenkins lab database for reaching out contributors and the digital waters. Instead of that, we just make the requirement that basically election is done by contributors. But the criteria for contribution is not just a meter. It's basically anyone who can prove a public contribution before September 1st this year. So that's basically the whole idea of the change. And yeah, it also makes a two-stage election official because it wasn't, it's not documented in the current election process, but it's effectively what we had to use last year because we were unable to handle a chief supporting for 100 southern participants. The system just doesn't support it. Yeah, I agree that we need to move forward with the change. I'm definitely plus one, mainly because I don't think last year's method is sustainable. So I think this is a great solution to that problem. So I'm plus one on this proposal. I have not had a chance to look at it, to be honest. But I want to do that. Can we respond via email after the meeting? Yeah, it's fine. So for me, yeah, assuming that, well, at least here it says that we intend to change the process. So what I will do tomorrow, I will actually document the process and submit it as a pull request to the election process. So in addition to this doc, there will be formal documentation for the process on this page. So I will do it the gutless, but it basically gives additional day or so for everyone to submit feedback so that they can incorporate it. And after that, I believe that we will just review it. And if the governance of the members agree, we will merge it. That's actually a question. Do we need to sign off at the governance meeting? We had talked last time about it, but I think we should take this meeting, sign off as presumptive, and declare that, yeah, we've got two members of the governance board present. We ask for sign off by email from other members of the governance board separately. I agree. Does anyone disagree with this statement? So basically governance board signs off the process, no new meeting, and assuming that there is nobody voting against the developer at least, we go ahead. Yep, sounds good to me. Everything looks good. Okay, then the bull is on my side to write this doc. A little permanent member. Sorry? This cake is still a permanent member. According to the current process, yes, I planned to reach out to Kiki, because yeah, well, how is the command that four members are elected? If Kiki decides to resign, all five members will be elected. So what? Only one person. Unless Kiki decides to resign. Yeah, I understand that it's not ideal. But I don't think that it's the end of the world either. For me, the main objective is to actually ensure that Kiki explicitly defines his plans before we do the announcement. And yeah, we will start, need to start sending out nominations, etc., in early October. So basically we have two weeks to prepare and start all formalities. Thanks. Yeah, so Tyler is up for the election, but Kiki by default is not. And another video for these other bottom members declared the intent to step down. Okay, moving on. Are there any other questions, concerns about elections? Do you have a set of fields that you would want in the form and I can start looking at creating the Google form? Well, I kind of documented it here. Oh, okay. Yeah, actually I plan to create a Google form. If you want to take this section item, I'm happy to leave it to you. Yeah, I'll take a look at it. Let's just take a nap. Okay, works for me. Anything else? Okay, then moving on. So roadmap review and again, we still need to conduct roadmap review meeting and informally. And again, it was planned to today, but so do you want to do formal go through in 30 minutes? Or do you just want to have a quick status update? What's your preference? I would love to at least have a status update, but I have to acknowledge that there are a number of things here that I have not yet updated that I should. I get plug-in performance improvements is from current to should be released and things like that that I failed to do. Well, it's basically community-driven thing and that's why we have roadmap reviews so that we can wrap statuses. Okay. So yeah, speaking of that, yes, we will need to update JSOC roadmap items. For example, checks API is delivered, have plug-in performance improvements. Is it delivered from your point of view, Mark? It is delivered. Yeah, we've delivered the major release and two minor releases are three with important fixes and he's continuing to work. He's working on additional enhancements, but I think it's delivered. So regarding the rest, dark theme, I need to confirm this theme, but it looks like it's rather in GE now. Same, for example, yes, so what else do you have? Plug-in management here, UX development, I think we can put in a preview because the rest of the work to be done after discussions. Team management, yes, dark theme, probably you moved to GE. And here, documentation immigration is still pending, so we haven't really complete immigration of any type of documentation completely. And it looks like a good opportunity for October 1st to maybe try getting it over the line. Right. And Jonathan Marais of the Dock SIG has been doing excellent work and getting ready for that and prepping for October 1st. Thank you. Contributions to your table studies, which I think we need to discuss the status. There was supposed to be a UX meeting today, but I guess it will happen in two weeks. But for me, it would be interesting to know whether we plan to merge because the main concern was about compatibility issues, not about the future readiness. So at some point, we need to make a call whether we merge it. So here, accessibility is kind of near term. Again, we could put some items for October 1st, but it doesn't look like we're ready to start the project right now. Modernized mirror infrastructure. Isn't it completed? Originally, it was moving to mirror bits. So the mirror bits move is complete. What's not completed is the disabling and shut off of the old infrastructure and the transition for windows. I think it's current. I don't think it is near term. It's really current and it's actively being used in production in many use cases, but we've still got a few use cases left to do. They were discussed in the infrastructure meeting on Tuesday. Tim noted two or three that we still need to do. So maybe preview. Yeah, it's at least current. Preview is also very valid because it's currently actively being used. Yeah, making notes because you rely on the recording. But Daniel, thank you very much for what you've done for update center. You're wonderful. Yeah, plus one. So here regarding terminology, Alex, do we have major changes there? No, we don't have any major changes. We're still working on it. We had the blog post PR that was put in that Markey did. That's just one small portion of it. So it's still kind of in that same realm. Yeah, we asked for requests to the update glossary. So now here you can find a controller that is still master, but this is the pre-created term that I think probably we need to move the pre-created terms elsewhere. But yeah, this glossary is updated. For me, what's important for this section item. So terminology updates and currently includes a lot of minor tasks. And we have Huck Weberfest starting in two weeks. So what could be done? We could highlight terminology now for agents and masters like this for Huck Weberfest. But in such case, we really need to have a set of tasks somewhere. As good hop issues or strengths, Jira. And right now there is still a link to the developer million piece. I believe that we took an action item to create these tasks, but I'm not sure who was it. I think the Doc's office hours is a good place to do that with Jonathan Morize and his work. Markey Jackson had a technique that he was going to describe to us once we get him back and available again. But I think that's a good one for GitHub issues in Jenkins.io. So that they're easily found by Huck Weberfest. Yeah, for Huck Weberfest, good first issues will be automatically highlighted on a random basis to Huck Weberfest contributors as well as the highlight through GitHub. I would say it could, well, if Jenkins.io website was in the Jenkins.io GitHub organization, it would have been even better in terms of highlighting. But it's definitely not the reason to move the website. So just creating good first issues could help us. And we also came to document this featured project. And this definitely marks section item to reward the Huck Weberfest page, right? That would be discussed as an advocacy and outreach seek. Yes, I still got that. Yeah, maybe we should move it to current with the assumption that we create this framework so that we can onboard Huck Weberfest there for a good idea. So user interface rewards, user guides, solution pages. Yeah, I guess it's like that. It's mostly, well, a declaration of intent. We still do changes here and there, but you know, it's a real life project. So here management and registration, remote and still preview, it still doesn't support Java 11. So I guess it cannot be moved to JEE. There is a public request from JEE for moving to JEE, but I think we are kind of locked here. Manage permissions. Yeah, basically, the scope still needs to be completed before we move it on. Because your manage permission is still didn't fully deliver on the defined scope. Oh, okay, because I thought that that manage permission and system read were included in 2.249.1, if not before, but you see there's some proofs. But before, but as preview. I see, okay. Yeah, so what has been done for system read permission is that in 2.254 we basically integrated it. So it's JEE. It means that we need to update those. We need to update this field. It's now released, but not manage permissions. So Gcast plugin compatibility, it's a kind of rolling effort, still a lot of work to be done. Window services, it's not even previewed because it still needs to be integrated into Jenkins before we move it on the Jenkins roadmap. Script security, it's blocked. The request is there, but it hasn't been integrated. Built-in plugin management is called. We had an agreement and Jcast meeting that we want to redefine this item a bit. Basically to have a roadmap embedded in a plugin installation manager tool. We haven't done it yet. But so it's rather near term. Though recently there was a 2.0 release with some changes. But yeah, my best feeling is that we will also need a 3.0 release soon because there are still some strange behaviors in the component. So I guess there will be more or less full roadmap there. Okay. Plugables configuration sources, non-progress administration guides. Yeah, basically the same, but the remote is monitoring the same. Okay. Is it final? If we press it like that, I can buy item. Okay. Jenkins Kubernetes operator. So maybe Alex, do we have some news after the discussion with Spertyshlap? So I had set your request for the email address for some folks, but you were already on vacation. So I don't think you saw that message. So I need the address for the, not the red hat side, but the other folks. I don't have any contact information for them. Okay. So tell us a follow up in the thread because yeah, I really didn't see the request. So if you poke me again in this email or whatever it is, be appreciated. Okay, we'll do. Okay. Okay. For Jenkins, follow around at one to zero. Again, there are some changes, but definitely it's not ready for release candidate. So it's still in progress. I believe I will move with, well, it's in preview here and because Jenkins, follow around it is available. But it remains as is. For external fingerprint storage, fingerprint preview is at the right state. So all APIs have been integrated, but some APIs have missed the LCS release. So they were integrated only in 52, you've got to call correct, 50, 53. So right now it's in preview. So if everything goes fine, you might be able to do it for the next LCS baseline. Also as I made it a pull request, which actually updates the plug both storage storage state. Because I think that we actually need to put all plug both storage on the roadmap explicitly. So what we have here, we'll just show the pull request because it makes it more explicit. Oh, it has been merged. Okay. So then it works as well. So it's development instance, but basically it's smallest. What was, no, sorry. It's actually all traversed because I switched another branch. It's here. So this is what is published on the website. We have a few stories. Maybe it makes sense to put them on the roadmap explicitly. So for example, build logs, it would be nice to have task logs, configurations, maybe not because after the Jenkins code arguably nobody really needs plug-in storage for configurations. It's arguable, but definitely doesn't seem to be a priority. Like code coverage results. Yes, it makes sense. Build runs, jobs. It would be nice to have it listed. For test results, team Gekrom currently is working on updates. So the G unit plugin has been already released. These changes to support that. Other results are reference implementation. They still needs to be hosted on Jenkins organization, but I think that it was being mentioned on the roadmap. And yeah, for the rest, yeah, other items, I also think it makes sense to put them on the roadmap if you'll add five additional items. But I think in this case it's reasonable because plug-able storage is a kind of non-stop for sorts of questions. And right now it's just external plug-able data storage, but you could expand it to multiple items. But okay, what's next? Jenkins on Kubernetes online meetups. I guess right now it's rather on hold because I guess nobody has time to host them. And I'm not sure whether it's going to change in the coming months. So the previous meetups were quite a success, but we really need a meetup host to keep them running. Yeah, I might be able to commit, maybe to run one meetup per month, but different not more. So let's see. Titan pipelines build step. Yeah, it should be in preview soon. We discussed it before because it will be presented at CDCon by BIP-HOP, but this item basically almost ready. There are some architectural issues to be addressed, but generally it's ready to try. Okay, Jenkins fast capability is basically Jenkins for the runner, but rather with tooling perspective and with packaging perspective. So I believe it remains as is and maybe when I have better roadmap for next phases. I will not rework it. The plan Jenkins on Kubernetes now should be in progress. So I will move it. Titan pipeline execution engine, maybe it should be moved to shut down because yeah, there is a lot of discussions already happening around that. But yeah, let's see. Like most of it should be discussed. Okay. Anything we miss for cloud platforms? Because yeah, there is a lot of topics, but it looks like all of them are related to items we have here on cloud native seek. Okay, packaging and platform support. Maybe Mark, if you could drive this part. So Docker images for S390, PowerPC64, OpenJ9. I believe we've still got that still in progress in that in the sense that there's an effort there. Mike, go ahead. Migrate to adopt OpenJDK has happened in Alpine already. And now we've got to make the change to migrate to or update to use the correct branding Eclipse adoptium. Forgive my mispronunciation. If I'm butchering the pronunciation. The name everything. And yeah, actually, yeah, so for that, here we have plugins. Jenkins.io and there is adopt OpenJDK, of course, in the plugin name and artifact ID. Right. And so that has to be changed to adoptium as well. Right. And so that that's but that that we've seen progress. The Alpine image has been updated to use adopt OpenJDK, the adopt OpenJDK, the adoptium project was willing to provide the Alpine image base for us. And it's worked out reasonably well. Or the Alpine build custom Jenkins distribution build service was a Google summer of code project. I assume we would call it in preview, Oleg. I don't think it's in production. It's more current. Let's define what you mean as production because it's here. Okay. So yeah, what we discussed there was a last edition attempt to get it hosted while it was a subject for retrospective in public discussion. But to be honest, I'm not really ready to even move it to the preview stage because right now it doesn't work. Okay, good. Then then it just stays where it is. That's even that's even better. We plan to keep working with Slavin to see how we can proceed. But as a service, it's definitely not ready. As a self-hosted solution, it might be moved to preview, but we will need to think how we organize roadmap because yet it can be two parts. Custom Jenkins distribution built to probably not, but they need to think how to call it. And the Customize Jenkins IO, then yeah, Customize Jenkins IO definitely will be preview. Right. So Docker images for ARM64, not any active work as far as I know there, multi-platform Docker images. The ARM64 ones should come pretty easily too. We have AWS agents. We can build those on. So we should be able to do those as part of like, even in the same timeframe as the S390X and PowerPC. Oh, good. So we can move that one over. Okay. So that one could be into the current column. Yeah. All right. Multi-platform Docker images. That was that's dependent on the other work, if I recall correctly, Alex. Yes. So yeah. Yeah. There are some prototypes in terms of code. There are pull requests merged in Jenkins IO Docker, but it's not used by default. Got it. Okay. Then in the far right most column, Java 14 plus support should now be updated to Java 15 support. They just released Java 15, but it is not an LTS. We need to look again to see when the actual JDK project plans to do an LTS. The last I heard it was targeted for 17, but there was noise in the mailing list that it might be 16. So we need to check that further. Yeah. The first set will be a good question because supporting the three JDK LTS baseline becomes problematic. At the same time, I do see how we could drop support for Java 8 into 720. Right. I think that's completely infeasible. Too many people critically depend on Java 8. This one is an open topic. I would rather let it sit and even wait until after Java goes with their LTS before we start work on it. So it's, I think Java 8 is much more valued in the computer community right now than Java 11. And Java 11 has been supported for a year or more. It's been actually almost two years now as an Oleg. It was 2.16 something. What's it for, I think? Yeah. It's one year and a half or so for official support in the Jenkins project. It's almost two years. So 25th of September, it will be two years of Java 11 in GE. Also my birthday, but yeah. Still, yeah, adoption in the Jenkins project is really low. So something like 1% or so. We can consider switching defaults for document images by default. I would be willing to consider that. But before that, I don't think we will get significant adoption. Right. Good point. And also, people need to realize that just because Jenkins is running under like a Java 11, that doesn't mean they can't do Java 8 builds. Yeah, it's documented, but there is documentation. And vice versa. You don't need to run on Java 14 to do Java 14 builds. So unless he just made it, yeah. Yeah, anyway, it's not a mission. Okay, cloud native Java support, yeah, definitely future. Well, I have some good progress in Jenkins for the runner. But yeah, extrapolating experience of Jenkins for the runner on Jenkins in this part, but it doesn't seem to be feasible. Okay, developer tools, yeah, we are running out of time. So yeah, just a release automation needs to be moved to done. Plug-in bomb preview as before. One question on core release automation. I don't think the branch has been merged into master yet. It has not. That is great. So that would be, I think, the final. Yeah, it's needed to be merged. All right. Or to be having a forecast for that. I don't. I was hesitant to merge it until we get Olivier back. That's probably a good idea. I was just being lazy. I admitted I was just being lazy. I didn't really want to merge it until he's back to help if there's a problem. Well, I second to that we shouldn't touch it, because you can see that there are much conflicts. But yeah, that's valid point, but we still need to finish that. So let's keep it. It is like, yeah, now on that theme, Alex is working an issue now for us on the Windows installer related to core release automation or to core releases. So thank you, Alex, in advance for your work on dealing with Windows in 8-bit fields. It's not one thing. It's another with Windows installers. Exactly. Hey, Oleg, back to you. Yeah, plug-in bombs, static analysis, local automation, dependency management, basically nothing changed. So it's mostly a documentation issue, but yeah. These bits, I will try to keep it as is on the roadmap. For the next infrastructure for experimental Docker images and a continuous delivery of Jenkins plugins, the incoming changes for Docker Hub and these cost issues reported for the factory. Yeah, it looks like these items are rather subject for reconsideration. So not touching them, but yeah, let's see. Rebuting to Jenkins, again, well, libido guidance have been refreshed largely. A JSOC is completed and Google season all docs is in progress, like it's listed. Coming into bridge, no progress. October 1st basically starts in two weeks. So happy to move it to progress. Yeah, that should be part of my pull request for the October best work. Well, I will submit all the roadmap updates in a bow. So you can leave it to me. Great, thanks. Okay, Jenkins is in the way. I'm lining it up for my Zs, LinkedIn, yes. Well, we can move it to release time. I don't think that there is anything else to be done there, unless we want to get premium account. Okay, he migrates Jenkins, our agents to AWS is completed. So we, I guess it's done. We have, we're still using Azure, but we do have agents on AWS. Yes. So I don't know if there's a plan to completely move off of Azure or not, but we do have agents on AWS. Okay. I think we can keep it as is. Yeah. All different. The stability is still no success factor. I'm not sure, Mark, what's your impression about the AWS agent's stability? It is still not satisfactory. You said it very well. I wish it were better, but yes, we've got ugly band-aids in place that help it. And yes, users have developed the bad behavior that they'll close the pull request and reopen it. Okay. Yeah, moving on. So funding on community breach, no changes. It's available in the preview, but we haven't promoted to it, which means we didn't really get any money so far. Although the process is documented, it's not working. So I believe it's on my list to push eventually over the line. But yeah, right now, if you ask about the status of Jenkins money, to be honest, we are not in the good shape. And it might become a problem in 2021 if we do nothing. No, well, you got a bunch of JSOC money. Okay, let's see. Core infrastructure initiative is done. Governance, bottom-up, set-adaption, chance-in-progress, technical student committee not really started. And I guess that's it. So for this roadmap, are we missing anything? I'm not aware of anything that's missing. Agreed. Yeah, then they'll probably just pull for stories we have on the table. Wait, maybe we should start it in conferences, some major engagements like CD-Con, DevOps world, etc. to the roadmap, force them to sell on 20. By the way, we're sure this year. Oh, is it? Okay, so they've announced it'll be, it'll be virtual? Yes. Do you know how they're going to handle the booth or the exhibit situation? I don't know. No idea. I guess it's still an exercise for everyone. They might do virtual booths, quite straightforward. They might not. Definitely for us it changes things. But yeah, let's see. Okay, and what else? Community advocacy, marketing. Yeah, I'm not sure what to throw it there. And contributing to Jenkins also need to regroup. Maybe add some plans for bots, but ultimately we need contributors to these areas. Right now, everyone looks to be at the limit of their capacity. So let's see. Maybe onboarding for contributors isn't the worst idea. Let's see. Okay, anything else to discuss today? Not for me. Oh, yes. I'm meeting with the Linux Foundation team today to talk about your migration. Oh, that's in progress. And no need to even put it in the agenda. But I've got to get going on that to be sure that we make it in time. And next meeting, we will include on the agenda JFrog Artifactory and what we know about that. There's really nothing to say this time, but next time we've got to discuss what have we, what have Daniel I learned about Artifactory and what do we need to do in order to meet their requirements. They stated that they want to continue hosting, but we need to bring the costs under control. Yeah, and it would be much appreciated. So, yeah, JFrog helps us a lot. They do. Then you should find a way. So, and for Docker, do we have any specific plans so far? No, actively discussed in the info meetings, but no concrete plans. Yeah, GitHub has recently announced that they will support anonymous tools from GitHub packages. So, it was just two days ago, so I can find a link. Great. Well, it definitely resolves our major concern about the GitHub packages or whatever it's called now, but whether it's not, I'm not sure. Okay, next meeting. So, this meeting is out of order. We expect to meet next week, but there will be DevOps world. So, and if you postpone by two weeks, then it will be decoded. So, my proposal would be to actually meet on 30s. And could you scroll down? I think in the August 26th notes, we had done this same calendar analysis just to be sure that... Yeah, and then October something. Oh, we had not set a date in October. Okay. Yeah, so we can meet on September 30th, or we can meet on, I guess, October 7th, and October 7th is the big one. So, one of the things that we wanted to do was be sure that we stayed aligned to LTS release dates. Let me look at the count. So, the calendar says we will release an LTS on, is it six? Seven October, so it was intentional that we met on LTS release dates, if I remember right, from Daniel's guidance. Well, we had a meeting last week for LCS. Meeting didn't happen, and I believe that it didn't change anything. Valid, yeah, good point. Yeah, so we can meet on October 17th for sure, but what's exactly the purpose? Yeah, September 30th is fine for me. That's great, and it avoids a collision with CD-Con, so I like that. Daniel, is it fine with you? No. No opinion. Great, so let's go with September 30th. Okay, fine with me. CD-Con and the WebSold. Well, I guess that's it for today, and yeah, sorry for going over time. Yeah, I need to think how to do the roadmap review, but at the same time, we just need to do it once per quarter according to the job. Right. So it shouldn't be a problem for the next meetings, at least thanks to everyone for your time. Thanks a lot. Thanks a lot for hosting. Yeah, so see you in two weeks. That's good, thanks. Bye.