 So without further ado, I am going to share my screen. So I can't share a single window, I have a problem with you. So I'm doing what I hate doing, sharing my whole screen. Okay, so do you see my screen? Yes, we do. So we're going to put full screen if that works. I thought it was this way. Anyway, let's keep this presentation this way. That's fine. If that's big enough, or that's not big enough, tell me. So, yeah, I wanted to make a quick update of the Guava work. You know, that was started some times ago. You may have seen, if you didn't, that's okay, because I'm going to explain again some updates here and there on the developers mainly, and so on, on some various efforts around basically being able to upgrade Guava in Jenkins Core. So in Jenkins Core, so I looked for an old cat picture. We have, we are using Guava 11. Guava 11 was released in 2012. And the last version is Guava 30. So we want to upgrade for various reasons. One main reason is security de facto. If we see if someday, you know, there's a CV that's discovered on Guava, old version, and we may be vulnerable. The Jenkins project may be vulnerable. And then upgrading, fixing will not certainly be easy, as you can imagine, because this is very old and nobody about, but neither Jenkins project would be able and willing to backport whatever. So this is a problem. So we'll start looking into what it would take to upgrade. So there's a JEP ongoing that was started by somebody else than our team. So because our team at Cloud Bees has started looking into the bigger picture, there has been a lot of efforts from various members in the community, not working for Cloud Bees. So I created just before the computer summit an EPIC, because I thought it would be nice to start and gathering things around. There has been a few PRs and so on that were started before. So this is the one I'm going to look into it for now. And then so James Nord on the call right now, I think. So started to look into some months ago, some weeks ago, what would happen if we would upgrade Jenkins Core, the version of Qua-Veinsat Jenkins Core from 11 to 30. Basically, James used the Rave API tool, basically a tool, Rave API, this one that analyzes the API and their backward compatibility and so on. And I did that in the mix using Usage and Plugins tool. That's a tool from the Jenkins community that's going to be scanning the whole bytecode of the plugins of the Jenkins ecosystem to find potential breakages, future breakages. So because going back to my slides, basically what we want to do is to upgrade all plugins to check whether they are working. So I'm going to show you, and it's going to be a good discussion following up the question earlier about the plugin, EOL policy, lifecycle work that some people here were in about the importance of clarifying what plugins we need to fix and the plugins that may be too old to have somebody care about. So this list is the following. This is the plugins that may be impacted by the Quava upgrade. So I'm scrolling, as you can see. A few plugins in that list are CloudBis proprietary because of the way we scanned, but that's most of them are open source. So you can see this is a small project, right? So why am I today talking about this? It's basically to raise awareness because we need the community to participate in that effort. Many fixes needed are a good way if you want to, you know, create your first open source PR. That's probably a good candidate work because most work are going to be, should not be very tricky in many, many cases. I'll explain afterwards what I mean by not too tricky. So yeah, we need people, but I'm going to now expand a bit more precisely what it takes. And you will see it's not rocket science. Any questions at this point? So what does need to be done to adapt plugins to Quava? It's, you know, you're going to look at a given and then you're going to upgrade locally. There's multiple ways to do what I'm describing right now, but that's one way is to basically upgrade locally your POM to force Quava 30. That's not in practice going to be used, but that will be simple and enough to run your tests using Quava 30. If that works, you're good, these plugins will work. And then we can consider this plugin is like, okay, stamped as okay to work when we are lending an upgrade of Quava 30 in Jenkins Core. If it blows up, then we need to fix this plugin so that it works with both. What does mean fixing, which here I explain here, it means that first recommendation is getting rid of Quava usage when that makes sense. If you're using, say, Quava, I don't remember the name, unmodifiable list, probably you can switch away from this one and use the collections.unmodifiable list API for instance as a standard from the JDK. That would be the simplest way when Quava is used, if you're using one utility class or something from Quava. If you can't, then you need to try, you need to make it work with the same code in a forward compatible way between Quava 11 and Quava 30. That means that your plugin, if you're doing nothing, meaning not forcing Quava, and then you will be using Quava 11, and then you force using Quava 30, you run just MVN verified twice, before and after. It should work and succeed the exact same way. When you're in that case, you are good. With the pretty important caveat that if your plugin has no test coverage whatsoever, what I'm saying is wrong, because then you won't see failures, you won't see breakages. But then, if this plugin is missing tests, that may be the right moment to add some, to show that it's not breaking. Then it's going back to usual development process, or maybe using code coverage tooling and so on and so forth, to cover the Quava usages and then going back to the process I'm describing right now. Questions? I was going to be a quick update, so that's everything I wanted to raise to discuss today. So if there's no question, that's fine. I think I'm going to... Is anybody just there? Yeah, not just looking at the right. That's somebody here I'm saying? Yes. Yeah, I was just a bit suddenly worried that I was muted since 20 years. So we're ready for you to start your presentation. Exactly, suddenly I had a small cold sweat, as we say in French. Okay, cool. So yeah, you see it's an easy thing. Just a few plugins to check. So, as you said, the reason why we're talking about this today is that there's something that needs to happen, but also that it's something that is very much parallelizable, right? That anyone can do it and... Yeah, absolutely. Yeah. It's a great opportunity, like for instance, in the Jenkins community for years, we have been labeling some JIRA issues as nooby friendly. I think most of these fixes are nooby friendly. If you're a Java developer, if you're not very much experienced in Jenkins development, this is going to probably be an easy one for you to enter open source, play with it, interact with nice people. We have cookies, and help this thing to move forward. Because basically what we want, I'm going to re-explain that very quickly just to step back. We want to upgrade Jenkins, the Guava version in Jenkins Core. But to do that and not make the whole ecosystem explode, we want to fix the ecosystem first. What about with all the plugins that are candidates to be the precators, applying the policies that we want to apply? All those plugins that are only compatible with 1,400 and this kind of stuff? That's a very good question. So, yeah, something like one hour ago we had a session that was pretty productive about plugin EOL policy and so on. So, I think the example you just gave is an easy one. We don't care. If the plugin only works with 1,400 probably those plugins are already dead de facto. But if a plugin still works on the 2,280 or 90 something weekly, yeah, that's a different issue. To be defined we definitely want to that's part of why we were pushing for this discussion today definitely that James was talking about because I think the Jenkins community if we manage to have a life cycle policy somehow it will reduce the size of the work needed for Guava. Absolutely. Those things are very much intertwined. Also, I ask because recently I tried to break the version of the Apache minor SSHD in the core and we managed to extract the plugin as mobile and we are struggling yet with repercussions of bumping the version and so on. And it's been 7 months or something like that to do a thing it's only one plugin and it has a few dependencies, 10 or something like that. We feel you. I think the thing to be to note here is that creating creating the PRs to make the change is one key step because then you can say look we've done our due diligence and the community has done its best here's the change. If it doesn't get merged there's enough traction in the plugin then you'll have a baby making very interesting noises on your lap. So as long as you've done that then there's a second discussion that you can have that says look we've done this nothing's happening it's time to let that go or someone needs to step up take over that maintainer shape or whatever it's not directly the EOL question but it's one where you can say we've done the work now it's up to whoever cares about this plugin. Yeah, that's what we've done for digester work and I think that pattern is one that we can continue to follow. To be frank I think this is an unideal pattern that's the least worst case or something the least bad way of finding PR but then that means still Liam that you need to spend time finding a PR that probably nobody would attend to. Right, my point here simply that I mean if it's a small PR then great if it's a large PR then maybe it's more problematic but as we were saying this is generally not a hard PR to do. Yeah, most often and if we have a large many hands make light work kind of thing going on then great, if we get enough people like that jump in on this hey if I mean I think that's another point here that that contributorship isn't just I did the work I did the work and it moved this project forward even if that PR does not get merged and I think if it doesn't get merged and someone new has stepped up and said this plugin is important to me so I'll kind of do this that's a step towards kind of getting that plugin maintained it's like hey it's important to me I've done this work I use the plugin and I want to keep me to keep using so it's hopefully a way to then go well this hasn't been merged and you know come to the community to that list and they'll go why hasn't this been merged and we say well you could ask to adopt the plugin if you wanted and become a maintainer of it I guess a number of tools that I've taken on contributorship to not plugins but tools it's like oh well I want to do this one thing oh it needs more help and that's how you that's the onboarding process right so yeah it's I agree it's not ideal but it's something I guess let's stay with this discussion or we can keep going I don't mind but the plugin EOL is kind of a separate subject even if it would help you know it's connected but different subject and you see why it was so important I alluded to that earlier today I did I think we're done it was really I think my next step is just I'm going to choose like one thing and one question somehow I'm going to update maybe send an email to the developer mailing list or something maybe the discourse should create a thread there probably and then the question is like do you think I should create a g-reissue for each of the plugins in the epic I could automate something to do that I'm not going to do that by hand but maybe that would I see you even I agree I was not thinking I was going to spend my evening creating 300s g-reissues so yeah that would that would be helpful but do we have a blog post for this because I think there's some interesting stuff to be talked about with this like hey you know Jenkins has these things and it might be a visibility thing there too because this is actually something that the community you know yeah that's a good point that's even more why you know I would probably want to create a g-reissue for each because then we have a blog entry and then tell people use this feature everything that's easy up for grab and you can assign yourself with the plugins you care about and then it's clear for you or something yeah yeah I'd be up for writing that blog post I'd be that's something I'd like to talk about it's the kind of thing where it's raising the why we're doing this what we're doing why it's hard why it's easy it's an interesting view into the community into the Jenkins plus you know absolutely doing what we're doing right now but at scale because right now we are the group here I don't think a lot of people are going to be watching and missing to that and so on making it believable to you know twitter account of Jenkins and the blog would probably also make the impact way bigger yeah so I've written some actions I'm going to write something on the dev list maybe on this course I will check with all the things the JEP we need to finish somehow but that's going to be midterm long term because anyways we know what we need to do for the plugin style of things create giras for plugins and then write the blog entry about the upgrade for raising awareness and getting hopefully scaling for free for those like hundreds of things to fix thank you everybody