 Welcome everyone this is Jenkins governance meeting it's the 22nd of August 2022. Thanks for being here topics I see on the agenda today include news. Action items. Upcoming elections. CDF topics. Jenkins.io website revert and forums and community topics. Any other topics we need to put on the agenda. Nope. Okay, great. Go ahead. There was a whole discussion on the blue ocean PR. Do we want to talk about it and that more I don't know if that's a governance thing. I think it well I think it's worth discussing we've got the right people here because Kevin's here you're here I'm here at minimum three people who are very involved in that poor requester here so yeah let the blue ocean disclaimer. Current status, and I've got some information from the past thing so let's carry that forward. I should have copied it in already. Here we go. And maybe what we call it is admonition so we use the same word every time. Okay. Any other topics that need to be added to the agenda. No, I'm good. Okay. All right so news. The Jenkins 2.2.361.1 release is scheduled for September 7 2022 it will require Java 11 or Java 17. No more Java eight support. Thanks to Chris Stern for volunteering as the release lead, the release checklist is open. Feel free to help out as this is Chris's first opportunity as a release lead so if you see something that looks a little funny, coach and encourage and help. Grateful to Alex Brandis for his ongoing encouragement and for Tim Gicom. We'll do a CDF blog post in addition to a Jenkins blog post and the upgrade guide and the change log. Thanks to Kevin Martins and to Basel for their work on the upgrade guide the change log etc. Any questions or topics on that item. Hey, next then action items and here I have to acknowledge. We've made some progress on the Linux foundation funds transfer, but it's not yet available in the final mode on the site the crowdfunding site should increase by about, I believe it was about. Another $1,500 or $1,600 after the Linux foundation has transferred the funds into our account that were given to us by Google summer of code 2021. So that we should expect to see further funds arrive there. Next action item was Jenkins docs signaling list I've made no progress in the likely be several weeks before I make progress on that. Contributor summit blog pass post no progress but I've made progress on other blog posts and the CDF zoom account this one I think Gavin you had the right approach, Gavin suggested forwarding the including a private Google group in the in the CDF mailing list right so that they would get all the notices of the, the token, when it's updated. Yeah, I mean the other option is just to add each person individually to the CMS but I don't know how hard it is to do because I've never seen or heard of this man listen to this week. Right. And that's, that's a Michelle mark no. She's a CDF person is the no, ultimately the one to decide and I think she'll pick the hey let's add one list and then let people subscribe and unsubscribe from that list. So I'll, I'll see if I can't push that forward with Michelle I think that's a good idea Gavin let's just do it. Anything else on the CDF zoom account question. All right, so next topic and I believe this was added by Gavin was upcoming elections. Yeah. Just was thinking about it. We do the elections every December ish November, which is coming up pretty fast. I believe specifically the board members who are up for election do not get involved in the election so that's me never lean on this year. So someone else has to be involved. And I figured the discussion is happening sooner than later so it's not a surprise is a good plan but Yeah, good suggestion so we've usually relied on the infrastructure officer. In that case that would be Damien DuPorto, but I don't know that he's aware that he's is that that usual person. There are two parts firstly is infrastructure part I mean this voting thing, etc, which can be duplicated from discourse. If we stick to the process from the previous year. And to be honest to this what I would advocate for to stick to the process at least once. And also there is all the logistics part like announcements waiting candidates etc is usually a governing board member doing it. I mean last year I live in everything so. Well, so is this one where we ought to put it on. I could probably be the one who takes on that announcement and betting candidates thing coordinated with Damien and if he needs to do the whole thing, or if I get overloaded. The candidates is for the entire board. Okay, at least how it's written in the governance document. Okay. Yeah, so announcements etc, whatever works. I can also participate in these things if some help needed. But yeah, I still cannot commit on my band wife. I mean, I will be definitely be able to send emails etc because everything can be used from previous years. So in terms of a timeline like the timeline then would be usually it's a September. Begin. Gathering candidates or gather candidates. October. And that means announce and gather candidates. And then October. Finalize candidates. And November do the voting. Yes, something like that. Within the new officers, new new officers. Effective early December. Yes. New officers and board members. All right, sorry. Yeah, thank you. New board members and officers. Yeah, very good. Okay. Yeah, so we could probably shrink the timeline a bit. Yeah, from what I've seen having long elimination period, haven't been very successful in the past. Also, yeah. So we need to confirm the new nations with candidates to get the statements. So for that one or two weeks would be a must. But I think that even if we started on October 1st, we could have completed this process. Okay. Sorry, Gavin, did you have some comment? Nope. Oh, okay. All right. How about let's put the mark to bring the topic. To the Jenkins info meeting tomorrow. With the info team, or maybe, maybe it's better to do an online discussion rather than put it in the meeting. So, we get the topic out there saying, Hey, here's what we think we want to do. Let's propose a plan. And so I'm all like I'm with you on the let's use, let's use discourse as the voting location again. Gavin, any reason that you have why we would not want to use the same voting technique we use last year. I don't agree with discourse with voting. I think we did discourse for this meeting. Oh, all right. I'm sorry, you're right. Right. It was what we did is we used discourse to register to vote and then we we use the, the system from Cornell to do a today do the actual voting. No objections to me though. I don't know if it misses. Well, yeah, no, I think the registrations part worked well I don't think how we were organizing the list of candidates inside of discourse as well but that's something that managers can decide how to organize it. I think user facing it should still be the same processes last year. Okay. And then voting through the through come doors it doors it voting system system at Cornell University, and they were, they, they had to actually use some emergency recovery work for us last year and seem to do it all right. Anything else on the on the upcoming elections. No, but if they want to host outside of the university I can probably help arrange it. Oh, okay, good. All right. Not necessarily part of the election but just because I think I can. The professor that that runs the server interacted with this very positively through that so Gavin may be able to host may have resource or access to resources. Okay, good. Excellent. Okay. Anything else on upcoming elections. Okay, next topic was CDF topics or like anything that you want to share there. Well, one thing if you're curious, there is a summary update on CDF to see activities in the to see channel on the CDF slug. So a few items from there that might be of an interest. So, yeah, I continue on as to see chair for another year after the elections in the to see. And as I said, it will be my last term. So, I have strong opinion that I shouldn't overstay more than two terms. So, yeah, so by August to 723, I will step down. One way or another from this post and will be organized and over. One impact on Jenkins that currently I represent kind of represent a Jenkins in the CDF governing board. And I keep pushing for topics like project infrastructure sorry for the outcome is not visible because there is no outcome, but be sure I push it every time. And the next meeting is on Thursday. But yeah, so I will be bringing up this topic there. Thank you. Yeah, so just go ahead because then there would be other topics. So I've, I've reached out with first hope to the cloud bees representative on the board. I just got back from vacation so I'll check again to see if I've actually got an answer in my email. Okay. And a few other updates. So first of all, a project to see was accepted to the CDF as incubating project is a distributed package delivery network. In my opinion, it doesn't really impact anything for Jenkins, including potentially upcoming changes in our factory plugin introducing the support to. I've already talked to Jay frog that it should be rather separate plugin. You know the story about the factory plugin. Yeah, also for pluggable artifacts storage etc it might be some follow ups. Another update. There is a new project started a CDF reference architecture. This project was presented at the to see meeting at the best practices meetings. I can share link to the slide deck. But ultimately is attempt to provide a reference architecture for whoever deploys application delivery flows, including CI or CD. And in theory, this reference architecture should somehow find balance between all CDF member projects and other projects in the ecosystem. I have no idea how it would particularly happen. Of course, we do have some interest that Jenkins is listed there. This is a recommended solution. Let's see for CI. Not 100% sure about CD but needs to be determined. I will share the link. So if someone is interested in this high level recommendations and the white papers. This is a project you might join. So how much would be for the community. So a few other updates. So the project called directive we likely apply for the CDF membership. So directive is a cloud native pipeline engine that is based on cloud events for receiving and sending events but otherwise it's let's say cloud native pipeline engine that is super flexible in theory and they actually want to introduce it in the CDF. So, like, did I get the name of that project correctly interactive. Directive. Oh, thank you. Okay, so like you all know it's like these because it's parents. So every time. But yeah, otherwise it's like that. So these might have some overlap is Jenkins well. I said many times that Jenkins pipeline engine should be pluggable. It's probably another use case. Well, another implementation possibility along with tecton which is already a part of the CDF. But yeah, ultimately, CDF is getting more pipeline engines. There are some discussions about other things for example about dagger potential interactivity to etc etc so yeah most likely this topic will keep appearing. Obviously it doesn't seem that we have any community bandwidth to make it a pipeline engine pluggable at the moment. I'm not sure whether we have much demand for that. Don't feel the messenger. Right, right so Jenkins pluggable pipeline engine is not actively developed. Yeah, I looked into that several years ago when I was working on a multi tenant Jenkins. It's not. And got it. The main problem that basically Jenkins pipeline has completely separate implementation of the engine and not integrated in the Jenkins core. So long story short, it will require some major league hacking. Yeah. What else about CDF. Basically, nothing I would say. So one thing to keep in mind that now we have a treasure David lie. So David could potentially help us with all the stories like Jesus funding, etc. Once he does the take over. I don't know whether all money landed in LFX crowdfunding, but if so, it's good. Yeah, and when I checked earlier, just a few minutes ago it the funny hadn't the funds had not yet arrived. I was glad to see Tara, Tara De La Mark and Alyssa both saying that there was progress, but finally funds I don't think have yet arrived. Yeah, if we look where some additional pump plumbing. Okay. All right, thanks. Any questions to Oleg on CDF topics. Okay next topic then was the blue ocean admonition current stuff. My fingers blue ocean admonition current status. So we've added a statement of the current state of blue ocean to a number of different pages. We had several additions. And then asking Basel to add the admonition to the plug in documentation. I think that's done right Basel, I've seen it and I've seen a website, as well as the read me and GitHub, when you find the repository. Great. All right so then we had one more which was at the admonition to the Docker of entry for the blue ocean container. I think that one is the, I think the most, the most needed because that container gets much less attention than any other than any of the officially maintained containers. Unfortunately, that one I've not done yet and I don't think anyone else has made any progress on it. I mean to bring up with the platform team. There is an issue with that one specifically and then in Docker in general, where people are installing plugins, expecting it to take effect the next time they launch a new image and it doesn't. Because plugins are installed to the rest directory and not the actual plugin directory. And Jenkins and startup doesn't override your plugins directory with anything in ref it only only copies new files or sorry. Non non existent files. So there's been a couple like that's what really was the big issue with the blue ocean upgrade and all the issues in the forum and people are like I downloaded the new image and it's still broke like, yep, that'll happen. Okay, so that's further motivation then to get people off the. Now is the standard container any different. Well the center continue to contain plugins are very few. They all get installed on startup and that's it. The problem is that it's a, it's a limitation with the design and not the block of blue ocean plugin or the blue ocean image specifically. Right so there's been a couple other people who have posted things like I've been I've been creating Docker image with these plugins in the past, but they don't update when I update the plugin you're like yeah you got to delete your plugins directory and let it copy the new files over again on top of them. Because Jenkins home is outside of the document here. I see. Okay. So I don't know what the right solution to this is, but it is related to this and something that we should think about further. Yeah, so it may need changes in the official Jenkins container as well. It may need changes in core because I think copying ref to Jenkins home is a core thing and I don't know who. Would we would we prioritize that because I don't see a strong, I don't know what the original motivation was to have a separate blue ocean image but I think the image was documentation to that motivation was to increase adoption I think it's already served as purpose. Yeah, no I'm pretty sure the container was just to be like, hey, one, one command will get you certain information. Right. And we dropped its use in documentation 12 or 18 months ago. So there's there's there's not really a compelling reason to do anything except deprecate the blue ocean container but I think what Gavin was describing may also be an issue in the actual controller container that we officially support as well. Like, like for me, I own his container with all the plugins pre installed so that can roll back if I need to, but I specifically have helm delete the flag in the home container or home to fig that deletes the plugin directory and start up. Right. So that's how I get around it but it's a really ugly hack and people who are not using helm like using open shift or just using Docker by themselves don't have that option. I think that would be, I think I've run into this issue in the past as well and I've done the same exact work around by deleting the plugin directory on startup. So I don't know if there's a ticket file for that already but that might be a good ticket to have in the either in the Docker packaging. But tracker or the core back tracker, because I think I'm familiar with this problem. I remember having to delete that director. Yeah, I have not brought it up specifically so I don't know if there's a ticket but it's been on my list for a while to, and this discussion of blue ocean reminded me to that I should bring it up for blue ocean specifically you know we could. We could just print a warning saying that this image is deprecated and then sleep for two minutes right that's pretty good right that would that would wake people up if they haven't. If they haven't noticed it. Honestly, I think, especially with Kubernetes you just hit deploy you wait till it's a bop and you're good to go you don't really wait, you don't go oh it's two minutes slower today than it was yesterday. But but finding a way, I think we do need to find a way to communicate to users that they're running a deprecated container. Yeah, I don't know what that method is but I think we owe it to them it might be an administrative monitor that says your container name is something we think you should not be using anymore. It's something like you write it filed to the disk the minute they've been monitor checks that file. It was cool you're running an image is based on one that we don't support. Yeah, that could be done as well. Wouldn't be pretty but it would get the message across. That's what matters. Yeah, and it would catch anyone who's extending blue ocean where if you're looking at the image you wouldn't catch that. So, but that's a platform thing not a governance thing. Right so topic for platform city. Okay. I'm very good at volunteering other people at understanding scope. Anything else on blue ocean admonition current status. Okay next topic then was, we had a Jenkins.io website layout look and feel improvement pull request that came in from a new contributor. After three or four of us had reviewed it we decided hey let's merge it. Then we detected several cases where oh wait it regressed something decided let's let's revert it so we've reverted now we're hoping that that contributor will continue he's expressed interest in bringing the, the change in as a series of smaller projects. I haven't seen any of those smaller pull request yet I'm hoping that the contributors is busy with the university, and we'll see them, if not, the concepts are there, and others could pick up and try those small improvements one step at a time. Did something recently changed with RSS feed. Oh, I don't, I don't know because I just got noticed, maybe they got published but I just got a notice yesterday I have RSS thing for the Jenkins thing. And essentially I got 123456 notifications and new posts yesterday for a week or two worth of blog posts so I'm wondering if we accidentally broke something and fixed it or it's just been my script maybe or something I don't know. Yeah, I fixed the bug in the RSS feed that had wrong URL. So that if your RSS reader uses the canonical URL that the feed provides. That might be a cause might be yes not my scripts I don't know. So, I think the individual entry URLs didn't change, but the canonical URL of the entire thing changed because it was still pointing to a course kid or test site that hasn't existed in a decade. And if some sort of ideas computed using that. It's understandable. Nice. Also welcome Daniel. Yeah, thanks Daniel. Okay, anything else on the Jenkins.io website revert before we continue to next topic. So I have a question about the review criteria for some projects in the for some parts of the project. It seems to me that for certain kinds of contributions. Reviewers would approve the contribution, as well as its exact opposite. Like if someone moves something from right to left. Thanks for the contribution that's great. Someone move something from the left to the right. Thanks for the contribution. That's great. So is this just a cynical idea that I'm having or would you say that's actually something that that user can see happening. Like, do we do we actually look at the man, approve the exact opposite. So in this particular case, I think the color scheme was changed from sort of a grayish thing to orange or something. And I was wondering about if a year down the line someone showed up and said, well, this looks terrible. We're switching from orange to gray would that be approved as well. Good question. I, in terms of my ability to review those kind of style changes, I am I on others case and sense and if they say they they like it, I think I'm willing to say yes, I like it as well. So, but would that prevent me from switching back in the future, probably not. So I think your, your answer at least speaking specifically about Mark weight. I think for anybody else but for me, there are definitely times when I would either approve a contribution or approve the exact opposite, because I don't worry about those two things at that level. So I think that's what you're saying right Daniel is merit of the change critically enough to not reject to then reject if it were the exact opposite. I think usually you can go one way. Going from something to better. But if you go from something to something but different. That seems like a waste of time of everyone involved. Right, agreed. Yeah, now in this case, I don't think it was actually going back to the opposite but I assume that your question was asking that as a thought experiment as a. Hey, is this indicating we need to be more careful in in our reviews of things to Jenkins.io. So in this case, I think I can answer the question with yes should be more careful because in this case is the fund was changed from a very deliberate recent choice to use the platform default fund. The pull request went to Ariel and feedback in the PR said we don't want Ariel, and then it was first removed and added back again and then merged, but I thinking about it more generally, if I don't know if a border is made rounder in the corners and then another pull request shows up and says, we don't want corners that are quite that rounded. One of the two pull requests should not be merged would be my position here and I now wonder whether we are in general prepared to provide such feedback. Well, I always try to look for justification and to apply the needs justification label if there isn't one present. You know so my, my criteria for merge for core is not only is this not introducing a regression. That's, that's obviously the criterion, but on top of that, I'm always trying to ask myself, what problem are we trying to solve. Is this the desired solution for that problem. In many cases, it's stated explicitly, sometimes it's only implicit. And in that case, it's harder to review the change because it's requires the reviewer to take on the burden of filling the implicit justification in their mind. And sometimes that could be very easy for the reviewer if they're very familiar with that area of the code. If they're not familiar with it and the justification is implicit, it can be very challenging. And in, in such cases, it's a fine line but sometimes I will avoid reviewing these types of changes and other in other cases I'll step in but ask for more explicit justification. I found that most people are willing to provide a justification if asked for it. It's, it doesn't, it's not, it's not in my experience, the request that's too, too much to ask. It's not like asking people to implement a very large amount of monotonous work or something it's just more like explain the problem you're trying to solve and how the solution solves that problem. And, and I think that's really the only, the only best, the best solution to this problem. And that, that can really change the conversation, because sometimes, you know, I ask that question and there's the answer I get is, oh, I didn't realize that the problem was more complicated than what I had originally thought or. Oh, now that now that we phrase it that way, there's maybe multiple solutions to this problem and this might not be the solution we choose. So just starting with the question what problem are we trying to solve. In other words, what's the justification for this. In my experience that's the best answer and I would never be afraid to ask that question as a reviewer or maintainer. Good guidance so for those of us who are on, we're doing reviews of content for Jenkins.io particularly structural changes it's a good, good place to ask for justification, good hint, thanks yeah. So Daniel in this particular case do you think that would have would have helped us get clarity I think here we had a large change that came in as a single change instead of a series of smaller steps. The proposal for the re redo of it is let's do it as a series of small steps, where we can evaluate each step. If that makes sense for the specific changes it's been a while already so I don't know the exact details but sometimes you are in the situation where each by each part on its own doesn't quite make sense and you need all of the parts together for it to really make sense right. I mean it's a general guideline in the project and I think elsewhere as well to have small or self contained changes. And if then you know there's one change for the color scheme and we can ask why. And if the answer is well I like orange a lot. And maybe that's not quite the justification we want for changes of this kind. I can see this also being a case of collision. So you know, someone coming in saying just change improves my life so we should merge it and you're like, we're like, yeah but you know you haven't really interacted with anyone outside of your narrow company or person. You don't know how it affects you know so you know because I've been thinking about how many how many times how many people we've had in the last couple weeks join various channels saying I want to get involved with the Jenkins community. I know Java how can I help and I'm like, honestly, you should be on the forums answering questions and seeing how people use the site before you're suggesting changes to the set to the thing. And you know this would definitely take that effect, or this would definitely help mitigate this issue where people are making changes because it affects only them and they think it's improvement but they don't really know how people are using it. But I've got a couple, I've got a couple of tier tickets that I could advertise to people they're interested in working on Java code. I mean, there's in the, in the newcomer's channel, there are a few people that joined recently bang out I want to, I want to help out where can I help out and Mark and I are like, here's a Derek list but we don't keep a, you know, I mean we could have a. Well, this is an off topic on that one. But I mean we could have a nice symbol landing page for someone to be like where can we help out but I think the important thing is we want to make sure that people are engaged with the community as a whole and not just the one person that it helps. Because that is what's called in the problem you know one person wants this font one person want this other font and back and forth. But I think there's also a lack of like community standards and I don't necessarily mean a full standard guide but like, I know we had some CSS issues there that in that big Jenkins IO thing that got reverted but most of us didn't know that that existed in the first place because there's no test for it, which is hard to do it. I mean no, no, it's, it's hard to test CSS changes but like from automated point of view, but like there's no comments, like saying oh this is specifically to handle specific bug I remember I fixed one which I didn't realize was a specific bug to different one. You know, so it's also very hard from a UI perspective to have that kind of long lasting documentation style guy and with UI changes you kind of just got to have someone go for guidance and that's just someone leading the whole thing. I mean, with with Jenkins IO specifically we are in the quite comfortable situation and I think it's all Gavin's fault that we have the test deployments, which, yeah, which actually makes it pretty convenient to just have the data and the test deployment up and compare them and see what changed. Obviously for more subtle changes that only affect the handful of pages or very specific pages. You might not encounter them, but I think the test deployments go quite a long way to make it easy to understand the implications of something and especially if you don't know what a change does or why it exists. That's an important review feedback. Why is this even here. I occasionally asked this in corporal requests changing the UI, because frankly I have no clue what the 10 level nested less does, or what it's for. And if usually the answer is good and sometimes the answers oh right that's a leftover from something that I can remove. So that's I think also important review feedback you can provide I don't know what this is for why does this exist please put a comment there. And experienced developers and mice in my that I've worked with have sometimes done self reviews where they will do a review of their own code where they explain the reasoning for every change that they've made if that that isn't something that's obvious from the code itself for the common ones. And, you know, perhaps not everyone would do that, without being asked, but in my experience that helps a lot, especially when you're making a change that has a lot of subtle implications. Self review is a great place to start. So, thanks. Okay. You know, so I was thinking about I'm always thinking about the preview environments because I am incredibly lazy when it comes to reviewing actual code changes as opposed to just reviewing the code itself. If we started to have standards in the in the PR template about what was changed. We could eventually have a script that actually generate screenshots to Oh, I see. So your idea was if, if the PR template listed the pages or the URLs of being changed we could, hey, give me a screenshot of this side by side. I think no matter what you should include a screenshot whenever you make a UI change in any way. Just because you want to highlight this is what I'm changing. And that should take effect for core or website or anything else. But that being said, I will be interested to see if we could set up or something like generate screenshots for like, hey, it is affected generate me a diff, you know, and there are CSS tools out there that will do that. So okay, the UI later on this page is changed. I'm going to show you before and after screenshot. Interesting. Good. Okay. Anything else with regard to the Jenkins.io website. Oh, I moved it to top level because I don't think it was Jenkins. Oh, okay, good to the review criteria topic. Okay, next topic then forums and community topics Gavin. Yeah, it's been quite a week or anything I wanted to really highlight. There were some comments on the last thing spring boot RCE post. I can't remember what the actual one was. Tim has closed it. I made a suggestion to close it to close it so no one else is going to comment being like, hey, what's the news on this new RCE this new alert. But it is something that we should be aware of that people are asking about. I don't know. I think in this case we should probably maybe one of us should write a comment on the bottom like for new, new alerts please contact security and then close the topic. So do we do we want that thinking about, we want to go that direction I guess I guess that's a, I'm not sure that the security team wants to be answering requests from people what about this. Because when they, when they detect an issues like on something like that I believe they publish the statement. If, if it's if we're affected right. So is there a drawer statement or a standard statement which pretty if we're, if we're affected will say so. No, maybe that's too, too creative. I believe that is exactly what the site says hold on. Oh it is. Oh okay. So I can respond here might be nice to you. Right, so do not contact the Jenkins security team, asking us for compliance documents certifications or to fill out a questionnaire. We will not respond to such queries if we consider it necessary to provide a statement in response to incidents such as log for shell or spring shell you will find a response in our blog, which is not exactly the situation right because we are not related dependencies, and people are worried about them but it does not rise to the level of everyone's losing their mind over this. So, yeah in this case, it was spring for shell blog post which was a good blog post and then now people are like is Jenkins vulnerable to the new spring framework vulnerability blah blah blah and I'm like, if I guess the standard question should be if we are will write a post about it. But it also is like a lack of communication doesn't mean that we're not vulnerable. It's hard to say anything nice easy for that. It's difficult right so because we typically would not say yep, we are vulnerable, and you're just out of luck for the next two weeks. So we would just provide a fix if it's important enough. I'm sure what the best approach there would be. We get people who basically report vulnerabilities if we will in dependencies in on the search mailing list, and in the security G round. And usually, it's in the form of them dumping findings from a security scanner on us, which is quite unpleasant. And we will typically tell them, we're not affected because we're not and we usually already are aware of these issues. And that's about it. How, how frequent is this so this is only happened once in the last two weeks, it was just a bunch of comments on the most recent spring family framework blog post. It's coming so many people lost this. So not many many but Tim and I decided to close it a week ago so only two got through. We're just like, honestly, this is an old topic it doesn't need to be rehashed. Okay. Gotta go be right back. Sorry. And then we can come back when I know if Daniel comes back. The next thing was, I was just pointing out there's seems to be higher than normal number of help request about James MPI I know Marcus dealt with a few and I've dealt with a few. I don't know what's changed I think it just happens to be this time of the year or something but it seems odd that we're getting a bunch of them all together. Maybe a blog post went out somewhere. Right. And I, I don't have an explanation for it either. I'm not overly surprised given random events. I assume it's, it will go. Apparently we don't have any involvement with it it's not in the Jenkins CI GitHub space is not published by anyone. You know, so honestly I'm just like, yeah, not our kind of not our problem. And I think that's a correct statement because it's published through the, the Python packaging system right. But it's also not in our repo. So we can't look we don't think there's no and it's very hard to find the actual source code for it because all the links don't really go the right places. I mean, at any point in the time I've, I've answered with, you should use configuration as code and they go, well we can't make changes and I'm like, by the way you should use configuration of the code they're like okay I tried to figure it as a code and it worked and solved this problem like, yeah, that's why I'm saying you should use configuration as code. Right. Yes. So, like I said, not really concerned just just kind of like one of those weird things that happened this week. I'm going to walk backwards, because we're waiting for Daniel but I did have another thought about the spring RCE. If we wanted to wait until later to talk about that. Let's do the next ones and then cycle back because Daniel might be back then. I'll list three more topics that didn't get a conclusion that we may want to push as the governance board to do. I don't know anything really concrete about the licensing and naming thing I honestly think it's fine for us to give them an A to use and you know Jenkins development for IntelliJ or whatever like that, but someone should officially reply and I don't really want it to be me. So, so this is one where I'm not sure how it how it works because it's this is not a company asking for a branding and naming thing. It's rather Dennis as a community community contributor has this IntelliJ plugin that helps people are doing development with stapler and stapler is a common Jenkins component mostly used in Jenkins. Yeah. The question then was hey what should it be renamed. It used to be called stapler framework support or is currently called stapler stapler framework support for IntelliJ. He was suggesting Jenkins development support. And I like Gavin your suggestion to follow the Linux Foundation guidelines ideas plugin for Jenkins development seems like it's using Linux foundation naming rules very nicely. I guess that IntelliJ has the same issue where they want their name to be last not first. Oh, right. My guess, you know, not not saying there's an actual published thing here but it's one of those things where both companies don't want to use their trademark as advertising. And this is not advertising this is just making a statement so I think we, it should be fine. But because the trademark is now entirely Linux foundation I don't know who can sign off on it and or if we care. Yeah, I'm not the expert. Oh, like you're smiling and I'm curious if you've got an opinion on this one. Well, for that I don't have an opinion, except the fact that it has been so this topic has been around for more than one year. So if Daniels is interested in working on this, let's just go ahead. And that's it. I believe you already reached consensus so that step that is not they used outside Jenkins and that we would like to rename it. I can pull the data but I was pretty sure that we had a consensus more than one year ago for it. We don't have to reach to the next foundation to say hey, we want to prove this or anything, or just go like cool, it's not a commercial thing we're good. Yeah, we are perfectly good. I mean, it's a part of the Jenkins project. We are eligible to use our trademark as we wish. Okay, I'm in the market you want if you're about to reply that good otherwise, I can try later today. Okay, I'm happy with you doing that then. So governance were discussed today and agreed that Jenkins development support. I would say as as it is a community project, Jenkins development support for intelligence is fine, or is approved. Good, okay. I would go with his suggestion though for an intelligent. Jenkins element for IntelliJ. I think that's what the topic says. Okay, let me see. Okay, sorry. Oh, just the Jenkins developers were fine. Yeah, sorry. Okay. So, as noted, or do you want me to open up the issue just for safety's sake let's open the issue. Okay, I got four minutes before I have to go so. Right, so I'm going to go ahead and say yes to that. So you're okay. Yep. Thanks. Got it. Okay. The next one is a prettier one, which I don't think there's any objections to it, though it sounds like some people are thinking my commenting about that I don't like prettier specifically, we're having objections to it. I just don't like the tool prettier. I'm cool with the whole setup and prettier as an answer. But either way, I think we should at one point just be like, yeah, sounds good. So it doesn't stay out because we have a lot of discussions to stay out really easily. Tim has requested a review from. Or last week, and I approved it. No one else did. We have a rule of two approvals are necessary. Okay. So today he requested a review from it from the core PR reviewers group. And that was just earlier today so no one has had a chance to respond to that yet. Okay, from my perspective all we need is a second approval to move forward with that. And then speaking of things that I'm afraid that might get lost is the Fort repository thing. I have some concerns about us having to do this again in the future because we haven't fixed the actual problem. But I'm totally in support and I think we should move ahead with fixing all the legacy plugins. Great. Yeah, so Daniel had a concern about something I wasn't following very closely, but from what I could tell that was the only blocker that was preventing us from moving forward. I don't remember what, I don't remember what the issue was. I also remember that. Oh, it was on the actual PR or actually on the help desk thing, not the email list. I think basically, if I remember Daniel's concern, there was very, we were going to do a bulk action on a large number of repositories and I think he just wanted to make sure that we had checked each one in the list. Let's see if that bulk action made sense before blindly. Basically, I think he was basically concerned about doing some sort of a dry run and checking the checking the list of actions before we go and apply it to everything. So you think there are at least one or two odd ball cases that we wanted to maybe skip the bulk action. I'm not misrepresenting, but I think that was, I don't think it was really a hard. It was more like, you know, let's just double check this before we because this is an irreversible change. Yeah, now that I'm seeing that I have to click on the help desk conversation I can see a lot of that discussion. It's not in the mail list. Yeah, so I think once, once we double check everything we should be good to go. All right. Anything else before we end we're hard stop on time. Any other topics. Thanks everybody. Recording should be available in roughly 24 hours we'll meet again in two weeks.