 Welcome. This is the Jenkins governance meeting. It's June the 26 2023. Thanks for being here. Topics I've got on the list include news. Action items. Upgrade from Jira eight to Jira nine. GitHub sponsors this one we may need to just defer. As a topic because I should have raised it as a question in the list before bringing it here. Budget and expenses just a summary and then a summary that I created of various community activity. Are there any other topics you'd like to be sure we add to the agenda. I have another topic regarding LFX tooling but we can do that at the end of you don't mind. Oh, okay, you bet. So, at the end because I forgot to add it to the agenda. Oh, there's I don't feel any shame in us adding things to the agenda wherever wherever makes sense great so okay LFX tooling any other topics we need to add to the agenda. Okay, well then, and if we do have topics that arrive we certainly can step forward with them. That's great. So in terms of items on the news. Today's two days from now Jenkins 2.401.2 will release. Thanks very much to Chris Stern as the release lead. And thanks to Kevin Martins for creating the upgrade guide and the change log. The CDF technical oversight committee elections are in progress right now. There are four seats on the committee with six candidates up for as possible candidates. I have already received an email invitation from opavote.com. And if you didn't, by all means you're welcome to reach out to me I can help with investigation as needed. The line for voting is to be. Say that again Oleg. The line for voting is to be. Oh, okay, thank you. Great. Thanks very much. In terms of action items we've got first easy CLA to be documented by Oleg and Alex has proposed documentation. And so for that. Yes, thanks very much and I, I have reviewed it and made my comments on it if others would like to view review it they are welcome to do so. I will review from me from me. I will try to do it tonight. Great. Thank you. Just requested review because otherwise, well, I will find it. That's okay I can, I can happily put you on as a requested review. Great. Alex was there anything you wanted to note as part of your, your work there on documenting it. So basically, I mean the easy CLA process is pretty much straightforward. Given you just click on the box comment file the CLA, whether it's an ICLA or CCLA click the submit button that's basically it you don't need to print anything out any longer or I don't know I think the old process was with GPG armoring and submitting that to the board. It's a more long gun that is handled by the Linux Foundation. The documentation I put in place just links to the documentation from the Linux Foundation, because they maintain their own documentation with screenshots, guiding you through the CLA process. They don't think we need to read invent the wheel there. Great. Thank you. Thanks very much. Any other items on easy CLA. Yeah, thank you Alex very much. So open action for me still no progress on the working groups transition, or retiring the Chinese Jenkins site further than it's already retired. It has already been removed from the header. So there isn't a Chinese selection here any longer however, the site is still available I believe it's at ZH. So, so we haven't taken the site down, but we also haven't received any new bug reports for the outdated install documentation that's that's visible there so I think already this first step has been a positive. And then I've still got the action, an active, an action item to archive the governance meeting notes. No progress there sorry, this one the retrospective on signing I've started detailing the timeline. And others are welcome to contribute. I've realized the timelines are actually two different timelines one for MSI and war, and one for PGP signing for RPM and Deb. And they have different they had different sets of problems and potentially different solutions, but I'm going to capture them in this single single document. Any questions or concerns there on those action items. Okay, then next upgrade from JIRA eight to JIRA nine Alex had noted that JIRA eight will be end of life later this year, and that we're using JIRA eight for issues that Jenkins that IO so I submitted a ticket to the Linux foundation, asking to schedule an upgrade, and they have proposed step one of the upgrade will happen on July six with an up to two hour outage for the database upgrade. Because the week of that week of the first full week of July is a good choice because in the US at least a number of people will take time off for the Independence Day holiday. So my thought was and they've, they'll do it Pacific time Pacific time afternoon. I think it's 2pm Pacific. So, after, well after working end of working day in Europe. Any questions or concerns about the JIRA eight to JIRA nine upgrade so this is step one a database upgrade. Then they'll takes later steps to perform other upgrades. Okay. Then next was, I've got a topic and maybe we should just let this one be discussed first, either in the developer list or elsewhere but what I saw was an article on new stack that talks about. Now allowing organizational donations to project to open source projects. And I wondered, is this something we should consider investigating further for Jenkins and finding a way to allow organizational donations from GitHub to be deposited into the Linux foundation LFX account where we track our funds. It's not that easy to do. Okay. So, we can definitely configure GitHub sponsors, and most likely it is something we should do, but GitHub sponsors. We're working on the UBS. I forgot the name of the service, but yeah there is an account we need to create. And this account would need to be created on behalf of the LFX charities. This is an organization. Oh, it's stripe account. So basically you have sponsors. He uses striped as a button. And then somebody, most likely the Linux foundation would need to somehow transfer the money from the stripe account to the Linux foundation. So that just I'm not sure it's really simple from the standpoint of the US law because a lot of charities is wrong profit and the Linux foundation is for profit. So most likely there is something else that would be needed. Okay, so, well, so I think you go ahead, Alex. I add a few thoughts to that. GitHub supports the concept of fiscal hosts for finance stuff. So you don't really need an personal bank account to transfer the money to. As far as I am aware the Linux foundation on the CNC F uses open collective as fiscal host to. I don't know if they use GitHub sponsors, but at least they have a fiscal house at open collective. It would be use similar to for the Jenkins project. But open collective is not the top sponsors. No, I mean, a GitHub transfers the money to the open collective account. For example, if we enable Jenkins for GitHub sponsors, the money would then go via GitHub sponsors to the open collective account of the Linux foundation, as fiscal host. So the money doesn't go to anyone's personal bank account. Yeah, it could be done. Well, basically, the tricky part for us is whatever we can figure it strike or open collective to get them on our account on a lot of facts. And the other problem as we learn is to actually use this money, because the process so far has been quite complicated every time we tried it. The question is whether we actually want to pull integration or whether you probably stuff on with the open collective account strike account and actually keep some cash there. For example, when you talk about the established to do so that can wait for a few months until the money are in goes. Okay, but if you talk about, we'll say, in terms of this depends and definitely can wait for several months. I think that we cannot go with a new institution. Oleg, I think you're one of the concerns you're voicing is the difficulty of getting funds out of the Linux found LFX crown funding and I agree that's difficult. I was worried more about getting funds into the Jenkins project. I think it's difficult to every time we do something specific like the summer of court. It requires so much funding that for small donations just makes no sense. So let's say several hours of work and the transfer and 50 bucks from the open collective account. I don't think that I would like to know. So this attention to have a kind of stable cash flow going through the system is one story. It's not what I would just stage this money as a standalone treasury and use it when funding. Alex did, did, did you were your were your comments understood and is there more that you wanted to note on it. I'm not sure that I'm understanding in detail yet. Yeah, I think I get Alex concern. Maybe. I don't know if there's an actual demand to use GitHub sponsor from our side. I haven't seen anyone requesting that we should enable that yet so I'm not sure if there's a demand. But on the other hand, I don't really track our crowdfunding profile within the Linux foundation so I don't know if anyone regularly add in dates there. Yeah, we have a few regular contributors. And we also have episodic one time contributions for the quite big ones. So, right now, the effects crowdfunding kind of works. I mean, we definitely receive more money there than we spend. Maybe this big expense report from our. But yeah, they think is that, again, we don't know how many people are ready to go to the Linux foundation service register the credit card on. Well, it helps us to be quite excited. And yeah, my good thing is that if you had this concept, the fall for us and we have made the option that was the sponsors file, it would help us to get some money. So I think what I'm hearing is based on based on no observed demand and I agree that I don't see any observed demand. And challenges associated with it we table it we know no further plans for now. Can can can reconsider in the future. Alex does that that work for you if we were to detect that someone needs wants to sponsor us through GitHub sponsors. Today we could point them to LFX crowdfunding and say hey pay it there. Yeah, I think we're already doing that. If I remember, if I remember correctly the sponsors file and GitHub points to crowdfunding, at least for Jenkins core. At some point we agreed that we don't want to put it in dot GitHub, because historically we have many years who have set up their own funding channels. So, and when we were setting up sponsors from the top, basically didn't work as override. So maybe now they picked it, but initially we just put up just a few repercussions. Okay, that makes sense. Great. All right, then. Is my order that terrible. I'm having to hearing you like a little bit. So they will try to find another headphones. But I think the topic is, is settled then anything else on that topic before we go to the next. Okay. So, and I think it may have been Bruno's actually microphone that was injecting some noise so I've muted Bruno. Great. All right, so next topic then was budget and expenses and this is just as far as I can tell we're up to date. The crowdfunding site shows our current budget balance. And so $8,763 US with my expense for the code signing certificate correctly shown, and the expense for the reimbursement to Vodek full on a that was took us a very long time to get done everything it seems to be correct there. Any questions on budget and expenses. And then was LFX tooling so Alex, this was a topic you had noted. Yeah, great to have all like here. You piloted the Jenkins project with an LFX security a couple of years ago. And I onboarded myself onto the project control center a couple of weeks ago to investigate into easy CLA and how everything works there. And I saw that the Jenkins project doesn't really use LFX security but uses it for the infrastructure organization. And I was wondering if there were any thoughts or concerns, why the we never on boarded that until the main Jenkins CI organization, given that as heavy use in other. Yeah, go ahead. So there was actually a pilot project between us sneak and the Linux Foundation. It was done as a part of LFX security to the zero. And unfortunately this pilot project couldn't go further because we were waiting for the Linux Foundation. So the story for us was that at that point I'm not sure about now the LFX security couldn't configure basic exceptions for false positives in any meaningful way. And there wasn't no facilities for organization management at all. So we used sneak directly it was possible but LFX security was basically reducing API to the subset that made it virtually impossible to use LFX security for Jenkins, without having 10s and hundreds of thousands of false positives. We spent some time talking to LFX team about that. And basically we gave up, because the LFX team was unable to provide us with a response what we actually do to resolve these issues. At that point, there was no even configuration through the repository available. And even now I believe that there is no global configuration through the GitHub. So, if we decide to enable it organization wise, it's going to be a pain for the maintainers. So someone is still probably wants to evaluate it. We enabled it for a few repositories so basically together with Olivier for a few intro projects where that are much more contained that Jenkins plugins. But Jenkins plugins due to the original packaging, which is classic Java packaging. It needs a bunch of patches to work as one would expect. Thanks for sharing your insights with me. Yeah, I was just a bit surprised, given Jenkins is the only project within the CD foundation, which is hasn't enabled it yet. So, but yeah, the background story makes sense to me. Yeah, so we could quite easily enable it for Jenkins core, but not for the plugins. At the moment, we could revisit that but why why couldn't it be enabled for plugins or like. Sorry. Why couldn't it be enabled for plugins, because every plugin declares an dependency on Jenkins core and other plugins and basically affects security as sneak by default. They basically take the dependencies as something that is bundled into HPI, which is not wrong. So basically, if you support the old Corvation, you get a lot of red plugs for all recent Jenkins security releases for releases of buggy dependencies, even if they're not physically bundled into the HPI file. How I see that makes sense. Again, it's a small matter of programming for classic stick, but LFX team when they were implementing LFX security one dot X, they basically did a design for that use case and we were dead in the water. And for LFX to to this way we started pilot because we wanted to adopt it. But at that point with an explanation team wasn't able to do it on that. So, and for communications, I still have emails somewhere but definitely we pulled from the project and it was approximately two or three months before I left for this. So, like, did I capture correctly here that if we were using sneak directly we could implement the the the awareness of the the special nature of plug in dependencies inside the Jenkins HPI files, but because of LFX securities, limited subset of sneak, we can't do it with elephant we couldn't do it then with LFX security. And this is important, you know, because I don't know what is the stage of LFX security now. Maybe they addressed some of the things. I mean, the whole LFX system has been in disarray due to some events. Well, they lost the product manager, then they lost the CTO pushing the LFX tools, then they basically had layoffs in the team, etc. So, I'm not sure what's the state of the LFX security right now, but ultimately we're still interested in adopting it. So there is an LFX tooling working group inside the CDF that has started their meetings. Tracy Reagan I believe is leading that. I've been in, I've been invited and I missed the most recent meeting. But intent plan to attend. Alex if you're interested I'd be happy to invite you along as well, particularly since you've got some interest in it. Yeah, I'm adding up to Alex concerns. I think the LFX security is more than just security nowadays given you can filter for blacklisted birds and go with dependency licenses is feel it feels like merging multiple tools into one that's like no longer really focus on just the security aspect. And like Alex said, they just added one single tool for scanning. So basically, it's now not blue jeans but something with a similar name plus sneak under the hood. But yeah, you're right that the scope were good expanded. But yeah. So what we have isn't really LFX security default because Jenkins uses custom packaging. So normally, if you do something like that you need to teach tools to handle the problem. But yeah, that's always a problem. Hey, Alex, anything else on the topic. No, that's it. Thanks for the explanation. All right, and oh like thanks. Thanks for the background. Thank you very much. Next topics I had we're on community activity and here my summaries may be weak so anyone should feel free to chime in on other summaries. My primary bandwidth reduction project is high on my list we met with JFrog last week and had a discussion with them they really want us to switch so that our the mirrors were maintaining of other repositories like repo one and the J get repository should stop because they're seeing a very high bandwidth use. However, that will require changes to our parent palms and that will require some changes to our use models and so we're worrying about how do we do that in a way that doesn't break things unnecessarily. So it's there's there's an awful lot to happen here in order to try to comply with JFrogs request. The next piece is that in UX sig meeting. Last week, it was agreed that the security team is going to heighten their reviews of changes to core for JavaScript and jelly for the next two months. So that we can assure that we don't to reduce the risk of having to do a security release to fix Jenkins with a due to a change in JavaScript or jelly. With the current activity in JavaScript and jelly it feels like it's a healthy thing. Thanks to Basel thanks to vatic felonie for that discussion and bringing it any questions on either of those two topics. No question just a little feedback. I requested three reviews from the security team earlier the same. That was three minor PRs. Nonetheless, all three PS got the green light within hours. So good. This is a positive sign that Alex concept is working out without slowing down and the time to merge of PRs. Very good. Thank you. The next topic then was prototype JS so in in our efforts to remove ancient code. Thanks to Tim Jacome and to Basel Crow prototype JS has been removed as a, the use of prototype JS has been removed from Jenkins 2.406 I believe and later. Optional flag has been added or an experimental flag has been added which will allow users to disable prototype completely. The epic is in progress. There's a lot to a lot of work to do to remove prototype from plugins before it can be removed from Jenkins core. This the tracking sheet shows the progress. Thanks Basel very much for maintaining the tracking sheet. Anything Basel that you want to note on prototype JS removal. No. Okay, thank you. Thanks very much for your your efforts and for Tim's efforts on it. Another upgrade is HTML unit two to HTML unit three, where we've now completed the upgrades for Jenkins core for test harnesses for the plugin palm and for the plugin bill of materials. There are some 250 plus pull plugin pull requests that have been submitted that are proposing the upgrade to various plugins, and there's a tracking sheet that shows how it's progressing. Basel I know you've been involved in this one anything that needs to be highlighted here. A lot of these pull requests to learn compiling it so they can't. You know I think that we should be making sure that they compile especially for the long tail of plugins with fewer than. I don't know 25,000 installations there's a lot of these that are orange, meaning that they cannot be merged since they don't compile. So be would be great to see some more work done to make these pull requests past the CI build so that the maintainers can then just click the merge button without having to do any additional work to get them to compile. Got it. Okay, so the color code here. This orange is PR file but not build passing and then it gets promoted to yellow when the build is passing. Yeah. So, below the 25,000 installation mark is a large amount of orange. Right. Technically it doesn't block integration unless it's bundled with the PCP or another framework like that. Yeah, although it's a liability in the sense that some future work will likely require a parent palm update. And that parent palm update will cascade into having to fix this problem if it isn't fixed now. Right. Yeah, that for me is the biggest, the biggest headache there is if someone doesn't do this, but then later requires a parent palm upgrade. If they're stuck they'll have to do the the html unit three transition in addition to everything else that they that might have been on their list so some urgent security fix or whatever could be blocked. Simply because they we we didn't get this piece of debt. They didn't get this piece of debt resolve first. I don't think that. Well, you have to mention the spirit fix that way updating the parent palm would be mandatory. So for me it's rather a minor risk. Okay. Anyway, thanks for submitting all this PRs. And then in terms of the color code. Oh right the the blueish color is hey we're just not worried about it and it we're not worried about it because for instance, four years out of date and well under 2000 installs those kind of things. Okay. Yeah, that's, that's great. Anything else on html unit three. Then next item was Google summer of code and it's progressing. We've got four student for contributor projects. Thanks to john mark, Chris Stern, Alyssa Tong and Bruna velocity. There are organization admins thanks to the four mentor teams. Each mentor team has at least two mentors involved most of them have three. And progress is going forward the next the midterm presentations will be July 6 2023. Oops, it would help if I put the right July 6 2023. Any questions on Google summer of code. Okay, then the last item I had on the list was early end of life for Cento seven. It's been announced. It's been declared it's now appearing in warnings it will appear to LTS users beginning with Wednesdays 2.401.2. So if they're running that old operating system we're trying trying in multiple ways to inform them that they need to get off that thing. Any questions or concerns there. All right, any other topics for discussion today.