 Welcome everyone. This is the 21st of August 2023. It's the Jenkins Governance Meeting. Thanks for being here. So don't have Uli or Oleg yet. We'll put those down. Don't have Kevin. So put that separate for now. Oh, that didn't work. Okay. So upcoming calendar items. We've got the next weekly schedule for tomorrow. And the next LTS the day after so Wednesday, we will have 2.414.1 Alex anything you need to share with us on the preparations for that since your acting is release lead. Not as far as I know. So there, there is a docker container thing going on with the intro team right now that we'll be doing a blog post on, but that's the containerization. Not, not specific to the build itself. Great. Then nothing else in terms of no upcoming announced security release or other major events. So I think we can go on to the agenda. And on the agenda for news. I didn't have any particular items. Are there any items of news that others would like to highlight. Great well listed is not applicable and let's go on to action items then. So Alex, we want to share with us the progress you've already made I can open up the nom the instructions you've given here on the voting tell us how the voting board and officer election prep is going. Yeah, this is based on the, the timeline is based on the timeline Olivier used in 2021. Given we hadn't have elections the past year. There have been no documentation and the documentation basically helped me to get into it how the civs work, how discourse group creation works, because I was kind of new to that. At least from a runner perspective. So yeah, I think the timeline is rather. Oops. Oh, go ahead. Sorry. Yeah, I think the timeline fits. So we have the final election announcement on December the 11th that fits with the past years and have registration open with at September the 18th. Until November the sixth, I think that is a fairly large time span, giving people the opportunities to sign up. Great. Thank you. So, so the please refer to the, the documentation page that Alexander's created. It talks about what the walkthrough it gives nice screenshots of how we conduct this. And this is the same pattern as you said that we've used in previous years where we vote using community dot Jenkins that I oh. Yeah, I recall this is the procedure I use in 2021 when voting for people, but given they haven't been elections in 2022 and that's almost been two years. People come people go, I thought it would make sense to create some documentation how it actually works. Yeah, very good. Very, very good. Thank you. Any questions to Alexander. The next topic then was retrospective on the signing code signing renewal process. And there the document is still there. I've made no progress since our last session. I will do my best to make progress before we meet again in two weeks. Likewise, I've got an open action item on working groups and that one. I will not make progress in two weeks. It's just going to sit there. It's not high enough priority for me to do it right now I've got other things that are more valuable. Last item is no one assigned to it particular and I wonder if maybe we ought to just intentionally put Kevin Martins as the assignee to retire the Jenkins, the Chinese Jenkins site and have him coordinate it. He's not here to answer for himself I'm open to comments from others. My redirect should be hopefully a small amount of work to add. So, I think it would be good to put a cap on or to tie up this, this project that we've been working on for a while. How about I like that idea, Basel how about if we set set ourselves a deadline deadline for four weeks from today for 43 no four weeks to close this one because it really would be. We're not serving the users if they're finding the old pages. Right. So let's let's get it resolved. Good point. Put it on Kevin. Any objections. Okay. All right. Thanks. Any other action items I might have missed or Basel there are their items that you wanted to highlight here on the. I see a separate item on the translation assistance plugin. Yeah, so this really is. That's not. That's not related to Chinese Jenkins site. This is more in this group we've talked about translation infrastructure as a general topic. I see either either in this group or in the documentation special interest group. The, the translation assistance is not going to survive the prototype migration. So I've deprecated it. And I think most of the functionality is now available through crowded, but I still think the user experience of the original translation assistance plugin was hard to replicate or it was really nice. I was not able to click within the Jenkins UI and submit translations. That barrier to entry was really low. So I thought that was a nice feature of the original infrastructure and I'm not sure that the, the new infrastructure is quite gone to that level of polish yet, but it would be nice if it eventually did. Very good. Thanks. Anything else with regard to regard to translation infrastructure. Okay, then let's go on to governance topics. So here we've got, we've got an open question from the Jenkins developer mailing list with regard to the JSON library and it's using a license that is not OSI approved as an OSI open source license. It declares itself to be open source or to be, to be, oh dear, what is the unencumbered word public domain, it declares itself public domain, but that's not OSI approved. And our statement on the document on the governance page says we accept OSI approved licenses I don't think we should stop using this library. I wonder should we broaden the allowed licenses we're willing to use or take some other approach. Interestingly, this is only the part of the Arc JSON, JSON Java library that changed the license. The original JSON thing or almost had that in the class since 2002. Okay, so I'm not sure I understood what you described there. So Alexander, you're saying that the upstream library of this thing had a had an open source license. The license of the Java library just adapted what upstream already had since 2002. So we have already used it passively through. Yeah, well just Jason packages Java library. And this clause, I don't have the exact wording in mind be public domain or something like that is already part of the upstream license for almost two decades. So it's not a new thing just new for the Java package. Okay, so here it's what you're saying is the public domain relicent statement of public domain is specific to Java. Okay, thanks. This is one I think may need more discussion I brought it as a topic here because it been raised but I'm prone to think I'd like to do or have someone else if others are interested propose. And how should we handle these kind of questions, because we've got a similar question from Daniel Beck in a message to the Jenkins board about other libraries, which are our different licenses that may not be OSI approved, or, yeah, oh, yeah, OS OS I recognize open source licenses. Objections from others if I just put an action item that says, let's start a discussion about how to handle licenses based on these two messages this Jason license message and the message from Daniel Beck to the board. Okay, since I hear no objections I'm going to put an action item there so mark weight draft a proposal license. A vision of a proposal to the board for would help if I put it on screen for license phrasing changes policy and phrasing changes. The idea being allow other licenses like the Jason license. Other approach, right. That's the question. We're going to be opening up this whole can of firms there's a topic that's long been on my mind which is what license should be used for a library plugin. Should it be the license of the library that's being wrapped, or should it be the MIT license as is the standard license for all Jenkins plugins and looking at existing examples. There have been both choices made in the past without seemingly any clear guidance there. So, if we're if we're going to be diving into this rather difficult topic, then this might be another question we try to answer. Very good. Well and since, since I had a conversation in the CDF technical oversight committee meeting about these kinds of topics and they've offered to give us some help from or to seek some help from the Linux foundation for these kinds of questions I think it's a good idea. Great. I'll, I'll, I'll post a draft I'll create a draft and we'll start some discussions about it. Any other license related topics we need to bring. That last question. If the, if the wrapped, if the, if the library plugin has no original code of its own. Then then it could make sense to me to use the license of the wrapped library, which is the case for most of them, including the ones that I've created. But there's other cases where the library plugin, not only bundles a library but also provides an abstraction layer around it. For example, in the HTTP, the patchy HTTP client library or the okay HTTP client library, or I can't remember which one now but in one of those two. We have our own Java code that acts as an abstraction layer for that library. So, in that case, do we want that to be MIT licensed or library licensed. Or is it that, yeah, how do we deal with hybrids like that. Yeah, good question. Very good. Okay. Any other topics with regard to licensing of libraries. Okay, next topic then was GitHub to factor authentication for many members of the of the GitHub, or of the Jenkins CI organization Alex you want to give us an overview there. I think, oh, GitHub sent the email out on the July the third, the 30th, I think if I read that correctly. And I thought what it was the same day that they will roll out to a for a majority of users within the Jenkins CI organization. I think. Yeah, the method we have opened this actually pretty accurate I was checking it a couple of minutes ago. Currently we have around 750 people without to have a out of 2500 in total. And now what's the, that is an, that is an improvement from 870 to 750 in just one month. I think that is a good rate, decreasing the amount of people who don't have to enable yet. What will happen. Is there some, some committed date where where GitHub access then is banned if you don't have to factor authentication enabled. Yeah, they put users into batches and I think 40 days after the batch you are effectively locked out of GitHub. There's a roadmap or somewhere but I don't have it at hand at the moment. Okay. Excellent. Thank you. We're seeing progress and if someone were locked out their solution would be enabled to factor and they're back in. Exactly. If you plan to continue to use a GitHub account outside of the Jenkins CI organization, of course, you have to enable to FA. Okay, great. All right. The next topic then was a question raised by let's read the ticket. This is an objection from this user Kosh dim saying hey as a Ukrainian. I would like us to change the link that we have today on the top level page from the international Red Cross to some other organization based on these other organizations now I don't have a strong opinion about which of these organizations are going to do or know and but all like Nenasha said hey he supports changing the organization reference to the Ukraine Red Cross or the official government accounts. I'm hesitant to make a decision here without having all like present but I'm open to others comments comments or concerns. I'm not sure I understand the link between the Red Cross and Jenkins could you please elaborate. Yeah, so that's that's that would have been a good thing to show right if we look at the Jenkins homepage. What you'll see is, let's make it big enough to read this paragraph right here. Okay, and this image stop the war we put those up when Russia invaded Ukraine. And, and I think we absolutely want to continue stating that we stand with the people of Ukraine and we want to encourage humanitarian aid. But what what the user was saying about all like was reinforcing is that the International Committee of the Red Cross may not be the best choice that there might be others that would be better choices to recommend in this hyperlink. Okay, do we have any stats about how many times this link got clicked. I don't. It's a good question. So it's just about changing the link to another organization maybe the Ukrainian. Okay. Yeah, so I'm only involved. No, no thing. Okay. Right. So when when I think you are see here would mean Ukraine. Yeah, Ukrainian Red Cross. So that was the idea. I mean the simplest is say a Ukrainian Red Cross is is a good choice as well should we just as a group here say yes we're going to approve this and use the pull request to work through it. Alexander any strong opinion from you. I've no concerns about that if I like, I think he provided a clear. Yeah, justification about that. And I think if he makes a call about that we can surely agree with them there can't be. Yes, great. So I think, given his sentence here is the u r c sounds like a good compromise. Let's put the action item out to I'll take the action item to submit a change, and I'll copy the board on it for for your your comments. And a change to Jenkins that I'll great. Let's do that. So next action item submit pull request to replace. I see RC link with you are ceiling on top page. Oops, you wanted to see the text there. Good enough. Okay then let's look at community. That's all that I had in terms of governance topics any other governance topics before we switch to community activity. Okay so on the community activity topic top of my list was Java 1117 and 21 and this is mostly for your information. Just to note that I've sent out about three or four weeks ago maybe a month ago now a proposal for some transition dates on Java support in Jenkins. The dates are highlighted here. October 23 of 2023 is proposed when we enable the Java 11 end of life monitor for an of an October 2024 end of support. So I should put it here. End of Java 11 support by the Jenkins project. And the next one, not 2023 2024 there. So the next steps for me on this one is to have a continue the discussion in the developers list in the users mating list and then I think the most effective way is a Jenkins enhancement proposal to say hey, here are the dates we propose. Let's move to and get started. Any concerns or objections there, things where you're you're worried. I don't have any objections this sounds good. We're a little ahead of schedule with Java 21 support I think in the sense that the ATH and PCT are now running on Java 21 already. We could honestly claim that the top 100 or 200 plugins that are in that suite are supported by Java 21, or that those plugins have have been tested with Java 21. There's no more work left to adopt their Jenkins files to run Java 21 on on their own pull requests rather than on the build materials test suite. What you did was you ran Java 21 tests in the plugin bill of materials and that meant it would test Java 21 with at least one Jenkins version and that 75 or 100 or more plugins that are in the plugin bill of materials. Okay. Big win. And what's the yes the default now for for weeklies in PCT and ATH. But it's still not being widely used in individual Jenkins files. Got it. Okay. Very good. Yeah, so, and I had intentionally left this date, sort of nebulous on Java 21 because for me that's a as soon as it's available as soon as we're ready to declare it. We've got to do container updates we've got to do documentation updates we've got lots of other places but I think October will be ready. All right, any anything else on Java 1117 and 21. Oh, I guess I take it back there's one important thing here that I wanted to highlight which is the proposal one of the proposals is. From 11 to 21 as the minimum Jenkins require Jenkins version in September of 2024. Rather than going from 11 to 17. The reason suggested by Uli Hoffner and supported by Tim Jacob was by September of 2024 we will already have had Java 21 support for a year. There is no reason to make Java 17 the minimum version it's let's just go to 21 it's it's a good time. Okay, so any other any other concerns or comments on that topic. All right, next topic then is Artifactory bandwidth reduction. And here we've, we've had good success with our initial prototype, J from sorry Mark, I can interrupt for one more comment about that last point. Yes, I think the requiring Java 21. Sounds good. Overall, but the risk that the risk about it that I haven't thought about very much is the old version of groovy that we use. And I don't know offhand, how well it's going to work with Java 21. I've already, I've seen, I've seen some small issues. For example, in job DSL trying to use the old version of groovy with Java 21 so far those issues have been limited to test only issues and not production issues. But I, I wouldn't be surprised if there were others. So, that's just something to keep in mind is. You know, as we, as we start to require Java 21 or higher. You know how does how is that going to also interact with with group with the old version of groovy that we use in the case of the job DSL plugin. There's a test suite that is running groovy based tests. And the, yeah, that that test framework. So what can support Java 21 but it also drops support for groovy 2.4 so you so you're kind of stuck. You're kind of stuck because you know you need to upgrade this library for Java 21 support but you also can't upgrade it because you're also dropping groovy 2.4 support at the same time. So this is, you know, going to become. Now luckily for us that's just a test library. So, I don't know, you know, we could we could just disable those tests if we, you know, and that would that would also be a problem I guess because we lose test coverage but at least it wouldn't be a production problem, but I could imagine similar cases to this. In production. So, yeah, I'm just not too sure what the impact of that would be just yet. But it's something to think about. Thanks thanks for the the alert that's a good one for those who are working on Java 21 be be very mindful of groovy and checking. Hey is pipeline working the way I expect is are all the details and things behaving as expected in Java 21 thanks. Very good. Yeah, because I think groovy shades, its own version of ASM, and it does not support the Java 21 bytecode, which it does support the Java 17 bytecode. But fortunately we don't, we don't call into any of these code paths anywhere. So it's, it's like, it's bad but it's not. There's no code that we call anywhere so it doesn't we don't have any errors but it's still something that's very, very, very tough to think about from a sustainability point of view, because you don't know what's going to call into that code path like that testing library, right job DSL happens to call into that code path. So, definitely something that makes me a little nervous. Yes, good point. Thank you. Thanks very much. Anything else on Java 1117 and 21. Okay, next topic then is Artifactory bandwidth reduction project. Here we've been discussing with the infra team and with JFrog, the host of our artifact repository, ways that we can reduce from what was a sort of breathtaking 50 plus terabytes a month that we were using nine months ago to get down to a much more reasonable amount. We've blocked one abuser and have successfully reduced others and have, we're delighted to say that the most recent changes that we prototyped showed positive results and JFrog has said, if we complete this stop mirroring in the central, they will consider that sufficient and so we're the infra team led by Damian and I are working on further prototypes will keep people informed. We don't have to do this adjust of parent palms. And that's a very positive thing to not have to do. We don't that means no requirement for a new release that means no touching the 2000 repositories that have references to our palms. So, so we like those kind of changes. Any questions on the bandwidth reduction project. But would we keep using the mirror for authenticated bills, such as those on our own CI infrastructure. It's not, I'm not sure if we're going to use the mirror or not at this point because my, my sense is that what we've got is we've got the artifact caching proxy right now that sits between our CI agents and the the public internet anyway. And we may just continue using the artifact caching proxy without worrying about mirroring because then we don't have to answer a an authentication prompt in CI and make the CI build process somehow different from users build processes. Yeah, I'm definitely in support of that because we need at least one level of mirroring but we don't need to. Right. And I think, I think that fits with what JFrog felt and what the info team feels will work well for us. Good. All right, next topic then was prototype JS here. So we just had a proposal a week or two ago from Tim Jacome proposing that let's make October 3 2023 the date when we implement the prototype JS removal in Jenkins core for a weekly release. That's a nice date for me because it fits with when we'll also enable the Java 11 end of life admin monitor to announce the next years, Java 11 end of life. So for me October 3 felt like a reasonable date. His comments in the in the poll request are good to read. Let's look at those here where he notes. JFrog has said they'll start on it in September to be ready. Cloudbees has theirs in progress and fortify is said there should be ready within September or October, and the 32 or three or four others. No response, but they are down in the less than 2000 installations each range. So we can see the summary here JFrog. Micro Focus fortify and then X ray co verity and Q test are each. Yes, they're more than 1000 we'd like to have them but if they don't come along. I think we could explain comments buzzled you want to share anything further on that. Yeah, I don't have any issues with that date. If we can, if we can agree that that date sounds reasonable I'll reply to the thread and, and, and say that I approve of that or that I'm in favor of that date I think once we, once we have settled that date I think Tim was planning on emailing these other companies to inform them of the date. Great. And the date works fine for me I think Alex and Bruno anything from either of you where you'd say oh no that's that's the wrong date. No objectives from my side sounds like a reasonable date. Great. Same for me as I won't contribute to that effort sounds cool. Great. All right last item then was HTML unit three upgrades. And here the tracking sheet shows how things are progressing. The, the most heavily used plugins are are making their way through it. We've, we've got a number that still need to need the transition. Since this is test I'm less worried about this than the prototype JS transition. But it is progressing any concerns or things we need to flag on HTML unit three upgrades. All right. That covers all the topics for today's meeting any other topics that you wanted to be sure we address. I don't know if it's the right meeting to address that but I've got somebody contacted me from adoptium asking if we wanted to be part of their. It's not a whole fame it's something that say this project uses Timurine, you know, I would give you the address. Where is it. And he was asking his name is George Adams, and he was asking if we would be interested into appearing on this page from Timurine. I think we are advertising as Timurine being our GDP implementation choice. Right. Correct it's it's the it's the JDK we use in our container images. Now we don't we don't prevent people from using others and we work well on others, but it is in our container images and, and it's also I believe documented in other places as part of our examples. So as it was during my PTO, I didn't contact you before that, but I already have raised an issue as they asked me to in their GitHub repo. So they wanted to have a logo if we were okay with that. And that's yeah, that's what I said. Okay, it's the issue I was referring to and the logo I proposed they did not like it so they found another one that like to use and I don't know if it's an official logo of Jenkins and if it's one we can reference to. Yeah, so if you want to send, if you want to send an email to the Jenkins board mailing list Bruno. If the board can take a look at it and see I, I would assume that they've chosen a logo that's a fair representation of Jenkins so why not. Yeah, let me add. I can add to that really quick the logo I have here on the issue linked is the official one you can get on get the Jenkins at IO. We distribute as artwork. Okay. Oh yeah, so if it comes from artwork then absolutely. Thank you. It's like the headshot with the Jenkins font next to it so nothing extraordinary. Great. All right, any, any other items that need to be discussed here.