 Well, welcome everyone. This is July 25, 2022. It's Jenkins governance meeting topics for today include news. Action items. Blue Ocean admonition. Embeddable build status plugin from last meeting. CDF updates if Oleg joins us and forum and community topics if Gavin's available. Any other topics that need to go on the agenda. Okay, then let's go back to the, the top of the agenda so by way of news, the next long term support release release candidate is due out on Wednesday with release two weeks afterwards thanks to Alex Brandis as our release lead. He's been the release lead for the last two long term support releases thanks very much. The upcoming conference, the Southern California Linux Expo in Los Angeles at the end of this week. Kosuke will be speaking and Alyssa and I are also speaking. Basel noted that Jakarta mail migration is in progress Basel what would you like to tell us about that. We just landed earlier this week or last week and the important thing to note for users is that they need to update some plugins and lockstep with each other. And those are indicated in the release notes. So, if you want to pull up for example the mailer plugins release notes, you should be able to see the messaging that we put in place. If you see that section that says related plugin releases, it's a little bit further down. But that, that gives you an example of, you know, these three plugins need to all be upgraded at the same time. That's an important note for users. And if it's actually more than just those three if you go back to the JIRA epic there's, there's a handful of them but those three are the most most popular ones. There's there's some additional for example I fixed up the SAML plugin and a mail watcher plugin, but those are installed on 2% of installations so they're not as common. The one thing that I would want to note in this meeting is that the disk usage plugin is kind of in a, in an odd state, so I didn't touch it, but that one could use a volunteer if someone is, if someone cares about using this plugin. The reason I didn't update it was that releases are currently blocked because there is, there is a security vulnerability that is on the main branch that has not been released. So the security team blocked future releases to prevent that vulnerability from ever being released in the first place. So if someone, so basically fixing this plugin up is is more involved than, you know, just submitting a pull request or adopting it there's some there's some additional catch up work that needs to be done, which I didn't volunteer myself to do. But if anyone is interested in using this plugin. I don't think it's going to work with the Jakarta mail migration. And I don't think any changes can be made to it until these security issues are dealt with. So that that would be a great example for someone to volunteer pick this up if they're using this. But other than that, I think we're in good shape with this migration. So, thank you well and Bruno Bruno and I are actually doing a session at DevOps world tutoring people as part of a workshop on how to adopt a plugin. We may pick this one as one of our candidates just to use as part of a lab exercise. So it's, that's an interestingly complex one. I don't know what the vulnerability is on the main branch. So, it might be a very simple one, like reverting one commit. So it might be a complicated one. I don't, I don't have access to the security tickets. So I didn't, I wasn't able to read it. There is a link to the ticket, which is private. So I think whoever whoever wants to take this on might might benefit from being able to read that ticket so that they know what they're dealing with. Well, and that that knowledge should probably then inform do I want to adopt it or not because if I'm not an active user of it then adopting it and saying I'm going to pick up a security fix, maybe more than they're ready to do. Thanks, good guidance. Buzzel anything else. No. All right, thank you. Action items. We've got a bunch that I have to sadly report I've made no progress on, and it'll probably be that way for at least another two or three weeks just for all the things I've got to do. Any questions with me now this one, the last one that we had put on last week, Gavin Morgan create a proposal to hire a writer. I think we may have a solution here that may address it I was hoping to have Gavin here but I wanted to highlight this at least to show people what. So Gavin's concern was that the ocean is not being actively maintained. It's not being not being actively enhanced. And because it's not being actively enhanced. That makes it difficult for people who arrive new to Jenkins and are then surprised. Oh this thing that's described in lots of places is not getting more enhancements. Certain fixes are being applied and security fixes are being applied when selected. So what Kevin has done as he's created a standard admonition to put on the page. And it says this kind of thing here, an info block that says blue ocean is not receiving further functionality updates. It will continue to provide pipeline visualization but will not be enhanced further. For me this was, and Gavin has seen this and said yeah that seems reasonable. Others are welcome to comment on the poll request encouraged to do so just wanted to be sure you're aware. Now what this this standard text or some variant of it will appear on most of the blue ocean pages like right now it appears on creating a pipeline and on dashboard, it appears on Activity View. So that users who are reading will see that status as they're working through their reading. Any comments or concerns there. All right, I think I think it looks great it's it's really good to be transparent about the status so I think the message is great. And I agree with that now I like. I did like the docs office hours Asia segment said hey, could we refine the message so that when we're talking about pipeline editor, we don't, we don't do as much to mention stage view but we mentioned specifics for pipeline editor and that's, that's I think we'll work with Kevin on separately. It's, it's I think it's an interesting idea of are there variations we should use for each of those pages that will make the message clearer. Great. If nothing else on blue ocean let's go on to the next topic then. Last, last time we met we had an item, an action item raised that the embeddable build status plug in bundles of was bundling a proprietary font. It's not allowed to be redistributed. And so it was violating the Jenkins terms for Jenkins plugins. And so what we did two weeks ago we said we'll set a two week clock. If no one adopts the plug in within two weeks we will cease distribution of that plug in because it's violating the terms. And in the in that intervening two weeks, it's been adopted and a release has been delivered that removes the proprietary font. Thanks special thanks to Basel for highlighting how to do that change. It was actually a very simple change based on his guidance, and the plug in now has a few more tests thanks to his guidance. So, release is done. It is still on CI Jenkins.io and better maintained than before. I think most of the credit goes to you mark for picking it up because I think that was that was very kind of you to adopt this very rarely used plugin. In this case I admit it was it was guided self interest. I didn't want the infra team to waste the time removing it. And so that's a that's a terrible reason to do it but it was cheaper to adopt it than it was to go through the process of removing it from all the infrastructure. Oh legs not here so I'm going to drop the updates from CDF and forums and community topics. I had two or three topics that I thought might be worthwhile, even without Gavin here. So, if you're okay with that. There is a discussion right now on a vendor site. What Gavin has proposed is a let's create a site called vendors dot Jenkins dot IO. That is a place where companies that provide support services or sell products based on Jenkins or etc could do place their information so that others can find it. Right now what we have as an outdated wiki page that points to vendors that are absolutely no longer active. So here's what his current prototype looks like. And what you see is we've got two vendors, a hypothetical vendor here that he created, and a less hypothetical vendor here that I created some rough data for now the data is not correct on these but the, the sampling is intended. Or the layout is an idea and what this gives then is a link here to more information about the vendor and a link to their support site, or a link to their website. The idea being, okay, this way. This is much better than let's do the search for Jenkins commercial vendors on the wiki page. And here it is this one is how it currently looks today. Actually, and Evelina you may recognize one or more of these, these names. Well, it's kind of a historical name. Exactly. Right. And, and that's what this page is sort of the, the historical wow it's not been touched in five plus years. And so it's so badly out of date that this is going. I would expect it was not touched for 20 years. Sorry, that's just a joke. I just wonder like how, how do we decide who ends up there, because as you pointed out, I know a company that I believe should be there or to, but do we have some criteria. Actually, any company that would like to place themselves there we would encourage them to submit some sample data so we can test drive it. Because that way we, we get a sense. Right now my, my, my scope is limited because I don't know all the companies that are providing products. And so I provided data but if you are aware of someone that would be willing to provide data, the data format is actually quite simple it's a little yaml file. And so, so it's, you can see the yaml file that I provided is someplace further down here. Here's the here's the yaml file that Gavin did. And here's the yaml file that I did this one. And if, if, if you've got a vendor that might be interested in being included we would love to have sample data from them. Okay, and then where do they send it. And if they just post it right here as a reply just like I did in this threat. Okay, and then because the companies I'm talking about the consulting companies that I know have consultants are really really good at Jenkins so that's kind of thank you looking for. Okay, exactly. And I, and I think that is, that is very well aligned with what Gavin's looking for what, what, what started his conversation about this was, Hey, we get people who ask questions on jenkins.io that are well beyond what a person who is doing this for nothing would do, but if we could point them to consultants to organizations that offer services for for fee. They may be able to get the answer they need. And the community can benefit overall because we're not just having people expect commercial grade support from a bunch of volunteers. Right, I, I don't work with these companies anymore but I'll drop them a message and direct them to the threat so they can just take care of that if, if they think it's the right fit, I mean I'm sure it is but I'm not a good job. Well, that would, that would be a great thing if you could just share a pointer to them saying hey, here's this thing that's being assembled. Get your, get your name up on this site. Thank you. All right, so next topic was that there is a new. There's a there was recently a series of 25 plus pull requests that were merged into Jenkins core to begin the process of getting us eventually ready to enable content security policy. So content security policy, here's the, the video segment is linked that talks about what it is, how it works and why we're doing this. We're still quite, quite a ways away from being ready to enable it, but it will be, it was promoted in last year's Hacktoberfest will be promoted again in this year's Hacktoberfest, and we hope work will continue so that the day will come when we can consider enabling content security policy on Jenkins core, and thus prevent a whole bunch of cross site scripting attacks with a single configuration. So, so just be aware of that it's no no action required yet from plug-in maintainers because it's most important that we get core ready first. And so Daniel Beck who's doing much of the work and vatic felonie the security officer are both making people aware without telling any of the plug-in maintainers oh you must do something right now it is just in core, and it's intentionally being done in a way that 100% compatible. Alright, so last item I had was on github comment ops. And I have to admit I am I'm really pleased with this the ongoing discussion talks about a technique that Tim Jacob has added for Jenkins core and several repositories that allow a, a comment to perform operations that normally are only allowed for maintainers like labeling a pull request or removing a label, or asking for reviewers by name. I found this to be at least for me personally quite helpful, because it means I can submit a pull request, and in the text of the pull request if I just put slash reviewer. K Martens 27, it will ask for Kevin to be a reviewer if he's got merge permission on that repo. So, very, very nice capability. Any other topics we need to go over today in governance meeting. Okay, I'll take that as an end. Thanks very much.