 Welcome to Jenkins governance meeting. It's the 17th of November 2021. Remind everyone that we abide by the Jenkins code of conduct. So be nice to each other. Agenda topics that I had include news, election status report and Gavin will put you on that one highlight from the mailing list and community forum. Anything else that needs to be on the list. You're way ahead of me on that one because I forgot to do that this week. Oh, actually, I wanted to thank you for creating the draft draft agenda it made my life much better by what you did so thanks very much Gavin also wasn't me but thank you. Oh, whoever created it that it's really marvelous that we've got it. Super. So news and election status report and mailing list highlights for the three topics I had. Oleg any topics that need to be added to the agenda. So, yeah, sorry, I have been a bit disconnected over the past weeks. Last time we had some discussions related to ownership, but it was brought up to the introduction team yesterday. So I'm not sure whether it makes sense to discuss it today until we get some clear details from the Linux Foundation about what they actually expect. This is the story about. So the Linux Foundation would like to have the admin GitHub account registered as owner for all project repair is it or is it organizations. Got it. Okay. Well, so let's let's at least put it there. We've got it as a topic and we'll make sure we actually maybe let's just put it as a top level topic because it's really not a mailing list topic right that's a, that's sort of an independent thing on its own. Great. Okay. Anything else that needs to be on the agenda. Okay. And so news 2.321 has released with new table layout, very attractive it's looking really good actually. And a new plugin manager some private plugin manager layout improvements and fixes to a number of regressions that had crept in to 2.320. Thanks very much to Jan Farachik and to Tim Jacome for their work there and to Uli Hoffner. It's, it's, it's really pretty cool to see what's happening in in the Jenkins UI, the 2.319.1 release candidate has arrived. It needs deeper testing I think than usual because it's got six back ports that were six different porous changes that were back ported, and has some some thing major improvements like the inclusive naming changes that we've got to be sure we have a great guide and well described in the change log. Kathy Chan is a release lead this is her first time doing a release lead she is in the same team that works she works with Bea Munoz and in the phone so who have both been released leads before so she's got good mentors. And last news item the Jenkins infrastructure costs look good for being in within budget. Congratulations to Damien de Porto and the rest of the infrastructure team for bringing costs down significantly in the last month. Any questions on any of those news items. Okay, Gavin you want to give us a status report on the election. Sure, a status is it's ongoing. We debated whether how much information we want to share publicly but I think we can safely say we have about 40 or so we have about 50% of the registered voters, voters have now read. Let's try that again. 50% of the registered voters have now voted. So we, we still have another what two weeks for everyone to vote. So we should be nudging probably again remind people to vote. This year was there was a snag that we have you have to activate your email with Concordia for your PC reasons so just another, you don't get an email saying to vote until you do that. If you don't get, you don't get any if you hadn't done it before we started the election, you don't get an email saying to vote. So now but could can we, or could the election committee send email to the registered voters, I assume we've got that list what we don't have as we, we have no association to know which voters have actually voted. Yeah, I'm, I'm only peripherally on the election stuff so we can bring it up with Olivia, if you want. I'm not concerned the next meeting is two weeks away I can not jump, but I think we'll stick with traditional methods, I don't know. Yeah, so I'll, I'm going to certainly be actively encouraging people to vote that that I'm aware of where I know their email address looking at looking at their names on the voter list. Great. Yeah. If they get spanned and have already voted it's no harm. Yeah, they've already voted they can't take their votes back. Exactly. Anything else on election. No. Okay. So then, like anything else you need to share want to share on the repository ownership. Well, I don't have much to share. So there is a kind of abstract request is quite clear justification that in the event that current maintainers and things become unavailable. The Linux Foundation would like to have an opportunity to take over the repositories so that the projects could continue, which is generally a good safeguard. And that's what the Linux Foundation seems to do for all the projects. But your engine source are on board it wasn't done for Jenkins. And now it's a kind of reasonable question but we want to have such recovery plan B, especially since we have a lot of confidential information. Security fix some private repositories and Jenkins in front. And of course, if we give owner access to GitHub organization to account with unknown number of users having access to that. Basically it means that any of these users can potentially exploit our continuous delivery pipelines and release something just by direct push for example. So security wise there are concerns we need to figure out. And again, yeah brought it up with Tracy Miranda. We still don't have information how it would be implemented what is the expectation, etc. And why just eat how why don't we do the same for Docker how social media, or probably should do it, but there is no guidance for that. So this is just a topic that concerns me because I do not expect us to easily build a consensus on this topic. Once we have clear guidance, we will need to have a conversation about it. That makes sense. Thanks. Anything else on repository ownership before we go to the mailing list highlights. Okay. So we've had, we had discussions, I think I started the discussions roughly two weeks ago on the docs triage team. I was there when I talked to the docs office hours participants Monday, late, late Monday, they felt like hey let's go ahead and put them in the triage team, even if they don't have assigned continue assigned CLA, because the permissions are so light on the triage team, no real risk there and we hadn't previously mandated it. So we, in some future day promote them to become a copy editors then they must have a CLA. So, so it'd be good for us to get the easy CLA implemented but it's not a it's not an urgent or emergency kind of thing. Yeah. So, I should be able to enable easy CLA quickly. If we present with a grid plan that we just reach the current flow and basically easy CLA is enabled only for our facility repository. So basically, if you need to say I'm silly, you just submit a request today with your metadata and then the board requires you to sign. It's straightforward. If there is meeting that I can enable that. Great. And I think, I think we had plus ones all around for. Yes, it was okay to go ahead. Had it been discussed, I thought it had been discussed in the devilist. Do you feel like there needs to be more discussion or you're looking for more plus ones or Let's just. Okay, my to the list. Perfect. Great. All right. Next topic was end of life plan for Java eight Bolivia. Lami had noted that jetty 9.4. 9.4 will end of life in the next one to two years. And that's not exactly a surprise. Right right no shock at all right it's. It's, they've already got jetty 10 and jetty 11 so no, no surprise that they would eventually stop supporting 9.4. When that happens that would be very, very significant to Jenkins because it's, that's where when when stone depends on that right so and jetty 10. So the 11 do not support job eight. So there's there's definitely a sometime before jetty 9.4 and it reaches end of life. Jenkins should be stopping its support of Java eight. The question is when and what process discussions are happening. Okay. Also the question is whether we go straight to Java 70. Oh, so one of the options potentially. Yeah. For me what I mentioned that the minute is the reaction to questions, whether we explicitly deprecated Java eight. And whether we have support for it. And so the current warnings are not are not an official deprecation, but they are they are there are current warnings and so your notion, the question was, shall we explicitly declare Java eight is deprecated with some targeted end of life date. Maybe without targeted date. So some great spirit. So we can say that we declared deprecated in one year, we might remove it or might not. But you can say that for at least one year it will be supported in terms of security releases, etc. Plus, we still have a question whether we would like to allow plugin maintainers to release Java 11 plus only plugins. Because we have all the support inside the Jenkins core for that. We have all the support inside the update centers. We just need to make a call and allow to release Java 11 only plugins. But obviously for Java eight users, it will cause some destructions. Most likely they will be sharing non core tools, for example, plugin installation manager for sure. There will be other tools relying on data direction. So, before we do that action, I would rather prefer to have Java eight explicitly deprecated. Makes sense. Okay. But I don't have strong opinion when we should do this. Right. Good, good insight. So, and I don't I'm in terms of. Gavin, I think you highlighted for us in our last session. This section of this meeting is really noting things where the board does not define these things and is not necessarily responsible for them. The community will choose, choose that probably based on an eventual JEP proposing some some plan of action. So I think this is for our information. We should also do the road map, I believe. Oh, right. That makes sense. So that is something that we manage in the would be managed through the government's board. Good. Good point. Thanks. All right. Next topic on the was managing GitHub access through repository permissions updater and Gavin, do you want to give us a how that's going what your experience is etc. Yes, so prototyping is going decently. We can read all the teams relative to quickly I think we figured it was less than a minute to read all the teams and all the members. The next steps would be kind of defining a format. There's some debate right now, because the RPU was designed for one purpose and it's slowly migrating for another purpose and that means some of the schemes are a little scheme is a little bit confusing. I admittedly haven't worked on it in a couple days, but the next steps for me is to find an easy way to identify when a new users added so we can validate that new user instead of trying to validate all users. Maybe I don't know if I actually care. Okay, because it could be fast enough to validate all the users we don't care. So, research is coming along. I think it'd be a positive win. Yeah, thanks so I'm, I'm certainly interested in it. That I think it sounds very promising. Yeah. Any questions for Gavin on managing GitHub access or related to it. The biggest problem is edge cases because we have many repositories that include external collaborators. There are some repositories which have different permission model. Yeah, I kind of don't care about those. I'm only doing teams and all repositories have access or should have access by teams. So I'm not going to manage the individual repositories. I'm just going to be managing the team so that people get invited properly and everything like that. And teams are a lot easier to get data back out because any for we have a JSON file that lists every user and what teams what repository they have access to and amends just can't be listed there because technically they get returned for every repo. I think we should fix that by having a very concrete this team has this users, knowing and made or not admit these teams have these members so I think we're going to stick with teams. And then we don't have those nearly as many edge cases. And at least to start I don't intend to delete anyone from them. We're adding new ones, members, and then we can get a report of what you need to be deleted. I don't know if we have even the bot, I don't think the bot can remove members either. So, you know, at this point we can only add them. And then, you know, if that works well and smooth then we can start having it be the source of truth so the team members get added removed from this but that's a longer project. But I think doing as teams makes it very clean and neat. Last item was just a word of note that FOSDOM is going to be virtual this year so the FOSDOM conference in Brussels will happen in February. And Olivia Venane it's stated that he plans to assist with others and again having a CI CD dev room. Those are all the topics I had. Anything else we need to cover today. Yeah, I might have some topic for the next governance meeting. But yeah, right now I'm still a kind of onboarding ported when your job, you know, my personal stuff. Well, and thank you for being here, Evelina calling in from a hotel room in Oslo so thanks very much to everybody being here. The next meeting will be with the new board or does that we usually wait another week or two. The next week will be with results preview I guess. So effective date for the new board is December 3rd as listed. Okay. So basically we'll have board members elect or something like that. Because by this time the poll will be closed you'll get the immediate results. Though there will be some period where people basically can do last considerations. But yeah, taking the number of candidates, I don't think there is much things to consider. Cool. So next meeting won't be just like normal except we might have more people. Right. Hopefully we'll have more people. Hopefully we have every meeting we have more people so Exactly. So all right, you should just a topic list for this Jenkins for Jenkins 11. We skip Jenkins 6 and go straight to JN 11. To see what people say. I see what you're doing. All right. Well, then why don't we do with Jenkins 360. Okay, I'm going to take off then. Thanks everybody. Bye.