 Welcome everyone. This is the 30th of October 2023. It's the Jenkins governance board meeting. So today's agenda includes upcoming calendar and news action items. Then community activity and two governance topic three governance topics. Any other items that need to be added to the agenda. Yeah, this looks good. All right, so in terms of upcoming calendar to a little bit more than two weeks from now we'll have a new LTS 2.426.1 without prototype JS without support for red hat enterprise Linux seven. And with showing a an end of life admin monitor for Java 11 users getting ready for one year from now when Java 11 will end support in the Jenkins project. We've also got an upcoming weekly tomorrow that has two changes proposed for backport into 426.1. And now there's a third Basel I think the remoting change is also for 381 31 81 is destined for this one so that's one that may be a third candidate. And we've got office there's there's the 31 61 I think and 31 81. I think there was some confusion about about what how recent how recent we want to go in the back for it, but I don't see in a particular need to be more recent than the particular issue that was fixed. So, there's no, there's no, there's no desire to get the latest version of remoting backported. Just a desire to fix the bug that was being encountered. Got it. Okay, so 31 61 then I'll double check that as release lead I'll double check that I think that means 31 61 is the good one and that's the one I proposed for the backport. Yeah, what you proposed I already reviewed and approved as being sufficient to fix the bug, while also not including any risky refactorings so that that was that that looked fine to me and I already approved that backporting PR. All right, thank you. Okay, so let me make a note through myself to remind me that the remoting backport already included is the desired version. Great. Thank you. Thanks very much. All right, then in terms of officer and board elections. That's the major event so where we have closed the nomination of candidates and voter registration continues through November 5. So, any any observations there comments there. So there was a there was a mention on the mailing list from Alexander that the nominations there's an exact count of nominees to roles. And so we may not need an election. That's how we've done it in the past and said we're not going to put a ballot out when they're exactly when the only thing you can vote for is exactly the candidates who are already there. Right, but I guess you should have submitted monomation so then right right and we we certainly sent reminders for nominations in many places and the nominees we got or the nominees we got. So that's just to action items then so the the board elections are running we did have we have 57 registered voters. That's down a little bit from last year where I think we reached 65 or 70 nominations have now closed. And that's all that I have on that one any questions on the election process. I did go around soliciting people to register to vote. I think we've done as much as we can to encourage people to go to the voting page and either register to vote or submit a nomination etc. Yeah, me too I had I had sent two or three or four invitations targeted at various people the Google Summer of Code past contributors Google season of docs past contributors. She code Africa contributors all sorts of different different people and I was a little dismayed that it's easy to register to vote and yet I think my success rate was only maybe 30%. So, you know, three out of 10 were typically registering. I got an interesting, I got an interesting response from one individual who said that they didn't feel like they were in the loop enough to register to vote, but they were actually an active plug and maintainer that participated in the prototype removal project. So, you know, in my mind, that's pretty qualified. I think, you know, you'd be hard pressed to be more qualified than that but I wonder if there's a gap in perception between people feeling that they're not qualified to register versus the reality being that they are. I wonder if there's something we can do to increase their confidence that that they really do have a voice. Yeah, I like that observation I'd call it imposter syndrome as a voter, and where it's failure to understand that you know an awful lot about an awful lot of things, and you would be a real benefit to have your vote. My, my technique, and maybe it's, maybe it's badly chosen but my technique was to send people a specific message saying, I need you to vote for me. I'm hoping that they would choose, oh, because Mark Wait asked me to vote for him, that they would choose to register. And again, even that 30% was all so I thought, oh I'm being a little manipulative and still I only got 30% response rate. I did not try to sway people one way or another I just simply pointed out that they should register. Right, exactly. So you, you weren't the shameless self promoter that I was that's. That I anything. Oh, go away. Just to double check. Do we have any officer positions contested, because if not, maybe the number of voters isn't that relevant. I think it actually is not relevant because we have no officer positions contested, and we have no board election board positions contested. It's just for me I was worried that if we didn't get registered voters and we needed to have a vote, we wouldn't have a fair representation. No, it was good that we solicited the voters because the timeline was such that if we did need to do a vote, the deadline to register was coming up very soon. So, if we if we're starting now that would be too late. Yep. Anything else on on the elections for 2023. Okay, next topic then is I've still got this action item and no progress on it on combining sub projects and SIGs into a single concept of working groups did have a conversation with people at CDF where they're using SIGs as a pretty term, but whatever term we use, there still needs to be a combining it's two things right now that aren't effectively any different for each other. So we need that. Retire the Chinese Jenkins site, Kevin, how what's your experience there. I've been able to check in with the infer team, and Damian departmental actually said that he'd be able to sit down and look at this with me go over things and actually just help me understand what's going on so that it's not just the infer team doing the work and having it done but so that I can actually speak to it. We just haven't had a chance to sit down and go over things yet. So, I'm going to partner with him to take a look at that and get that sorted out. But yeah, just need to set up a time to do that. And then the idea is that once we have that meeting I can go and then walk Mark through as well and and explain how this is all set up for him. So for the knowledge share. Great. Thank you. Thanks very much. I'm going to take that deadline off of the Kevin I think the crucial thing here is we want it done well enough that it works. Great. Yeah. Thanks, Mark. All right, then I had the action item to draft a proposal for to the board for licensing policy and phrasing changes what we had is. We've got some licensing exceptions right now in the things that we're delivering like Jason the Jason license is public domain and for OSI public domain is not strictly open source. And so we've got some some open questions like that. I had a conversation with representatives at the Linux Foundation member summit last week. And I think I've got good guidance on how to go forward. I was guided last time to say, hey, let's look at other projects that are using mixed license mixtures like Pi Pi, and see if we can use some of theirs and then we'll invoke the help from the Linux Foundation legal team to review the proposal for is it saying is it sensible, etc. Any questions on any of those. Is this something that I could help with if we're trying to get this done within the next couple weeks, or is this something that we're comfortable letting it sit in the back burner and I should continue focusing on other things because I could, I could try to work on this if we want to try to wrap this up soon but I also don't want to spend a lot of time if it's not that high on the priority list. For me, it's not that high on the priority list. I don't think that it's, it's a threat to the project when the when the Linux Foundation summit had a presentation about legal threats to open source projects. And this was not one of the items on their list. So, given that I thought, I think it's it's okay if we rather keep our focus on the higher priority more more more user valuable things. We're not worried about the initial basis for this conversation with someone posting on a developer list about some plugins that were bundling the JSON jar file inside of them. That would normally be something that we take urgent action on to, for example, stop distributing plugins that violate our hosting conditions, etc. But this didn't seem like one of those cases to me, because most of the examples that we found, or at least a vast majority of them were already had already upgraded to the latest version of that JSON library, which is in fact licensed appropriately compared to the earlier versions. Was that am I remembering that correctly? Well, since it's at least the current versions are public declare themselves public domain, not declaring themselves MIT or Apache, but then OSI says oh, public domain is not an approved OSI license. Right, but so the point I'm making is, yeah, there might be some ambiguity about whether we currently accept public domain in the Jenkins project or not, but that's still a lot better than using the outdated version of the library, which in which case it wasn't even public domain. And I think I think the vast majority of usages are using the new version. So I'm not concerned about this is a high priority. Now, if some prominent Jenkins plugin was still shipping with the non public domain version of this library then that might be a more pressing issue for me, but that that isn't the case. Good. All right. Any other concerns on the licensing policy topic. Okay, then next topic is in terms of on community activity. We've got this ongoing discussion about the Java support plan. And I've opened up a Jenkins enhancement proposal which has now been through enough reviews that it's ready to have a JEP number assigned to it and be marked as draft. You're welcome to review that further. It's basically moving to a two years supported, two years required, two years no longer supported model in the six year life cycle of a Java LTS release. The only thing that I wanted to start. The only thing I wanted to discuss in this meeting was where should we, where do we want to document the because we're kind of evolving toward this process of either using automation or a very well defined process for doing these migrations right because they're going to happen more often. And there's a set of steps that need to happen every time, many of which are now automated, such as this, the administrative monitor being automated, but there's still are some manual steps that need to be done. And that includes, you know, I just discovered one the other day like updating the windows MSI installer. That's one that we always seem to forget, because it's at the back of a lot of our minds. But I've been accumulating some of these steps in a big block comment in Jenkins core. At least the steps for adding a new Java version. But I think we should also document the steps for the other two, the other two events in this timeline, which are not just adding a new version but making it the recommended version. In other words, the default in the Docker images, that's another discrete event in time that needs action where there's no automation and a third event in time is dropping support for the old version. And again, most of that has been automated. So, you know, the administrative monitor will has the end of life date baked into it from the day that it's added so that that part is automated but there's some other actions that need to be taken like updating the palm to require that new version in the compiler settings and things like that. And I don't think we need to make a concerted effort to envision every single action but I do think we should have one place where we try to document the stuff so that over time, we can automate more and more of it and also so that over time we can ensure release leads or, or contributors that want to work on this can just go to that document and know exactly what they need to do without having to figure it out from scratch every single time. So, I don't know if you want to use that block comment and Jenkins core in the Java doc, or if you want to have some other. Yeah, I don't really care where we put this material as long as we decide on where we're going to put it so that's what I wanted to talk about in this meeting was like where do we want to document all of this. And how do we want to maintain that documentation. I've been quite pleased with the concept of a release checklist that we use for the for the Jenkins LTS releases, because it gives us a GitHub backed version controlled document that we then instantiate every time when we're ready to do it would that be okay for you because for me I would love to have a checklist that says, making the Java version the recommended version don't forget MSI don't forget Docker containers don't forget this. So then do we want. Okay, that's fine do we want one checklist that covers an entire Java version in all three of the stages that I described, or do we want three checklists for each Java version one for the addition. One for making that the recommended version and one for removing support for it. I've preferred I've preferred the shorter lifespan of one for add one for mandate and one for drop. But I'm open to others for me, I like it when I, it makes me it gives me a warm feeling when I get to close that issue that says this LTS is done. And if we put all three into one I wouldn't get that warm feeling until six years or four years later. No, that makes a lot of sense. The only downside is that we just have more objects to instantiate every time I want to run through one of these check but that's that's not a very big problem so what I can do as far as I'm working on this blog post and a bunch of other communication related items so what I can do as part of that is, move the instructions that I wrote from that Java doc comment and core into a checklist and you said you want you said you think the release repository would be a good place to host that. It's whatever repository put it we put it in needs to have get hub issues enabled. And so, for me the release repositories a better choice than Jenkins core because I don't want to enable GitHub issues on Jenkins core. Right, right. Okay, that's that sounds good. I'll move the, I'll move the checklist that I started working on from that block comment into the release repository. But that, like I said, that's only one of the three checklists. So, as we, as we perform these actions for the next in the next few months. I'll at least make placeholder checklists for the other two events, and try to sketch out what I think should happen but we won't know for sure. Every single item that needs to go in those other checklists until we start actually doing it. So, we could only anticipate so much but I think. Yeah, I can already see I can already foresee some issues with dropping with with dropping support for Java 11 in a year, because that that creates some challenges with plugin builds that are still trying to support multiple core at the same time. So, you know, we came up with one solution for dropping Java 8 support, which was not not an ideal one, but which was I think the best that we could do I think we could maybe do better with Java 11 support since it would be possible just to toggle a setting and plug in poms and get the right behavior, but we've never actually done this before so what we'll have to discover how this really works when we actually do it a year from now. And, you know, maybe, you know, ideally this would be part of the jet but I think but I wouldn't insist on it. But yeah, it's something that that we will that we will need to do in the future so I mean at least in theory the JEPs are supposed to be descriptions that's something that's already been implemented. And this is part of that implementation is removing support for the old version, which I don't think has really been either actually either done post Java 8 or documented in the JEP, but it's not a blocker for me we could always add that we could always add this I like I like the idea of the documentation about JEP specifically say that they can be revised and that they should be revised. So I think putting a link in in the in that JEP to here's the here's the beginnings of the release of the checklist for Java beginning of life here's the checklist for Java becomes the mandatory and here's the one for Java end of Yeah, I like that. And for me it's it's a reminder that Java 8 end of life is actually not that far away either. Okay, it's further away than Java 11 but there the day is going to come when Java 8 stops stops being supported by the Java vendors as well. Yeah, because due to the fact that the palm changes for Java 11 were so drastic we couldn't support Java 8 and Java 11 from the same plugin palm, which we theoretically could with 11 and with with nine and up, because it's only two properties that are different. So you could have, you could have a plugin palm that required Java 17, but which still was used by a plugin that required an older version of Jenkins that still supported Java 11. The only thing you would have to do is set two properties, the compiler target and the test compiler target. Now, whether that's something that we actually want plugins to do or not is a separate question, because we like, like I said we could do what we did with Java 8 and just make a flag day in the in the plugin palm and force everyone to do that migration at the same time as upgrading the plugin palm. And that has some pros and cons. But the other approach that I just suggested also has pros and cons. In theory, this should be part of the JEP discussion is having the the debate between these kinds of engineering tradeoffs. Yeah, one thing to keep in mind that right now we're talking about maybe in three, and maybe in five is about being much more flexible with regards to release and profile management. So maybe these won't be even a question anymore soon. Yeah, agree that Java. Well, what I've seen Java 8, we could have supported it with Maven 5 but as of now there is no point in that and should be there such some drastic changes in the future I think that we would be migrating to Maven 5 at that point anyway. I've been following the Maven developer list, and it seems like they, it seems like they have been making a lot of changes for the upcoming version of the upcoming next major version of Maven but all of them seem to be compatible. In the sense of, you know, these migrations that they do in the Maven project take like five years to get through, you know, we think that our migrations are long if they take one year or two years, but they have a very broad time scale but yeah like it seems like Maven 5, which is like next plus plus one or next next, that one seems like it's going to have a lot of breaking changes in the sense of they're reducing the visibility of a lot of public APIs. And I actually do worry about what that means for things like our test harness because we are relying on some of these APIs being opened up, but in any case we won't need to deal with that until like six years from now or something so it's quite far away into the future. Well, if there is a need we could be great earlier, but as long as we can do this existence Maven without Java 8 I think we should be just fine for now. Great. So, anything else on the Java 1117 and 21 topic. The next topic then is just to announce that Hacktoberfest ends in one more day. And John Mark Mason has sent messages to the dev list, we're about 30% less than we were last year in terms of contributions, but for me we also see dramatically less spam. So, and that positive actually. Yeah, because there is no physical tissues. So we see the same in other projects. So if you see 30 50% drop it's okay. Good. Excellent. So other topics so we've talked about the board and officer elections topic already and I think that one is is final resolution final announcement coming from Alex and final announcement. Alex and really, and that will come. I've got one topic here that needs board discussion this is the, we've got a $40,000 Azure credits donation from Microsoft. Very very grateful it's been sent to the board as a question but I wanted to discuss it here in this meeting so what Damien is asking is hey, hey we've got a current Azure subscription type that allows CDF to pay their bills by invoices. But we can't use credits to pay the bill so the current subscription type won't allow us to accept this donation. We want this donation very much because it's five plus months of our infrastructure bill in Microsoft. So, Damien asked the board, give me your advice on which of these three paths, you wouldn't you think I should take in terms of getting this, this donation, best absorbed into Jenkins with the least risk to the project. So the choices are change subscription type twice, wants to use the credits, and wants to go back to the old style. That's first alternative second alternative is change the subscription type once and then persuade CDF to switch to pay the bill with a credit card. Then the third path is use an entirely different subscription to host a portion of our workload and keep the existing workloads on the, the thing that CDF knows how to pay. So the, the strengths and weaknesses, if we do the convert forward and backwards, Olivier Vanan has warned Damien that the last time he made this change he spent months getting it adapted to the CDF payment processes and the Microsoft processes. So, the worry was, if we make this switch, it may take us multiple months to do it. The other alternative attach a CDF credit card would be fine if CDF's willing to do that. But that means we've got to coordinate with them to make the switch and have them now pay with a credit card instead of invoices. And then the third path is just create a new subscription that does our ephemeral workloads are Kubernetes based and start a new virtual machine and tear it down based and use that. That one though requires a valid payment system for the new subscription and so we'd have to find somebody who's willing to put their credit card on the line for the for these ephemeral workloads that will be backed fully by the Microsoft donation while we're using it. Questions comments concerns preferences. Oh and Damien prefers option three. Yeah, option three seems like the lowest risk option to me. No objections. Okay well and that was my, my take was, I like the low risk because manipulating these, these accounts and subscription types is, I've learned by painful experience with the Oracle cloud thing just how difficult it is sometimes for these cloud vendors to adjust their payment processes or for us to adjust our payment processes. I think Oleg given that your comment and Basel's both say, let's go with option three Damien's recommendation. I'm going to go ahead and reply to the to the message from Damien that that's the three, the, the, those of us in this meeting said yes and then let Uli and Alex and Kosuke if they want to reply differently let them reply differently in the mail of mail thread. Great. So for the, for the CDF, we have all the payments logistics sorted for now. Yes. I guess in one year you might have this question again but for now. Yes, yeah the, the payment for instance I am proud to state that the September as your bill has already been paid by CDF. Yes, yes, victory. Congrats. I mean, so no is no disruption to the payments to buy CDF to Microsoft for and, and I'm proud to announce that Damien that the info team kept our costs under, I think it was just under 7,000 that month so very, very nice savings. We, we budgeted 10, and they, they took us to, we were well under eight. Great. All right, anything else on that topic. Okay, last topic is just a summary of Oracle cloud costs, Oracle cloud still hasn't made their invoice have anything other than a $0 do. And I can't yet find a way to justify why cloud be should pay an invoice that has $0 do. So I'm still waiting for them. Any other topics for today. So something like, is this a case where, like with GitHub. We, we had that event a few months back where we, I wanted them to absolutely confirm that the trust and safety issue was resolved before we move on so this is something similar where we're just waiting for them to confirm. Exactly. They, they, the choices here are, they either need to tell us, yes, we found a way so that the invoices are non zero amounts so that they could be paid, or they tell us they're donating the equivalent that those those costs to the Jenkins project. So it's done. And yes, it's, it's blocked on that and I regularly ping them about every two weeks saying, Hey, it's been two weeks. Have you changed that has this thing become visible and their answer is, Oh, no, but can you figure out a way to pay it even though it's not visible to you. And my answer back is, I'm sorry, my finance people don't like paying invoices that have $0 do they don't know what to do with that. Yeah, okay. All right. Thanks everybody. Recording will be available in about 24 hours. Thank you very much.