 Welcome, this is the Jenkins Governance Meeting. It's the 11th of December, 2023. We've got a number of topics on the agenda, including upcoming calendar, action items, community activity, and governance topics. And underneath each of those, there are several items to cover. Are there any things that I may have missed on the agenda that need to be put on the agenda from your earlier review of it? No. Okay, and let's go ahead. So upcoming calendar, Wednesday of this week, we'll release a new LTS, thanks in advance to Chris Stern acting as the release lead. And release candidates been in testing for about two weeks, looks really good. Next weekly release is tomorrow. I don't have anything particular to flag as hot, interesting in that weekly release puzzle. Is there anything that you're aware of that we should highlight coming in that weekly? No, I don't think there's any breaking changes or anything like that. Great, okay. All right, we'll take a two week break in the long-term support release cycle. So we'll release Wednesday and then six weeks later, we'll release the next release. So on January 24th of 2024, so that we can take a two week break at the end of the calendar year. I'm not expecting a change in the weekly release schedules because they happen based on a clock. And so I also think there will probably be a slowdown and commits to them during that period, but they're just going to happen. In terms of next major events, Fosdham 2024 is coming to Brussels, Belgium, February 3rd and 4th with a Jenkins contributor summit on February 2nd. Uli, I understand you're planning to be there and we've got plans to have others there. We look forward to a great conference. Any other items on the calendar? Okay, next topic then was news and I didn't have any particular news items. Are there news items that others want to highlight? Okay, then let's go to action items. Basil, you want to share with us how the attribution entries for the downloads page? I know you've done much more than just the downloads page. Tell us what's up there. Well, I decided to start by just creating a sponsors page that lists all sponsors because that would clarify in my mind the types of sponsors that we have and the levels of sponsorship so that we could then create subsets of that list in other places. I know we have a subset on the homepage and we'd like to have a subset on the downloads page but before I could create these subsets I had to understand the whole list of sponsors. So I started by working on a generic sponsors page and I think we've settled on we've settled on a few levels. I think we've decided on three or four levels of sponsors. So the next step on that is to go through the data of contributions over the last year and sort these sponsors into these levels. So I just got access to the data very recently and the idea is that once we decide on this naming for these levels we would classify all of our existing sponsors into one of these levels and then I'd go and update the draft pull request to correspond to the actual levels and sponsors sorted by their amounts and there's a lot of graphic design that's involved in that to make the logos look good on the page and things like that but that's kind of where I'm at right now is I just got access to the data and I'm working on classifying the existing contributions into levels. Thanks, thanks very, very much. Any questions from others? Great, thank you. So in terms of the data that you're using Basel that includes I assume the financial data is there other data or do those of us who have other involvement with sponsors need to give you some data to help guide those things? I don't know yet. I need some more data I'll ask for it though. Okay, great, thank you, thanks very much. Anything else on the attribution entries and the sponsors page? Okay, next topic then. Damian had the action item to create an issue to switch agent implementations and that's been done, he confirmed it to me. Next topic was Alex and Uli run the officer and board elections. Uli, you wanna give us a final summary there? Well, I think everything is now finished. Alex provided a blog post about the results and he managed to assign all rights for everybody. So I think Basel, you have all rights now in the groups and I think he removed also the rights from Oleg so that everything should be fine now on this side. And I think we can remove this action item. And great, thank you. Any questions from others on that one? Thanks Uli for running it. I'll remove it so that it's not on future agendas. Next item is the pull request to reorganize into sub projects and SIGs into working groups. No, no progress and no progress expected probably for a month or more. Just I'm not at that level right now. Kevin, retire the Jenkins site. You wanna share with us how that's going? Or retire the Chinese Jenkins site. I should say things precisely. Yeah, so pretty much in the same places before still working on trying to understand the configuration in the backend of stuff. Yeah, once we get that figured out, we'll check in with Damian again to see what the next steps are, what realistically we can do. And I've been looking into the rewrite functionality to understand it better and make sure that that's a viable option for what we're looking to do. So yeah, and I've been working with Mark on that end of things. Okay, and by rewrite, you mean like URL redirects? Yeah, so essentially the way it's configured, using the Ingress it figures out the path that it's supposed to call or lead to, but we can update that change or include a rewrite function in and that would update it so that the path is looking at just the regular Jenkins.io site instead of looking at the ZH Chinese site. Thank you, thanks very much. Any questions for Kevin? Okay, next topic then was a proposal to the board for license policy. And here, thanks to Basel, there's been progress on it, not of anything I've done. Basel submitted a government document poll request to accept public domain licenses, which is one of the things that started this. Basel, you wanna give a brief description of that? The poll request allows explicitly in addition to OSI approved licenses, it allows public domain dedications as well as public domain equivalent licenses. I think two of which are already OSI approved, but the other two of which are not. So the practical impact is allowing public domain dedications and the additional two public domain equivalent licenses that are not OSI approved, which are the unlicensed and I think CC0. Thank you. And so on that poll request, I'd already approved it, Alex had approved it. Uli, are you okay with this idea that we would accept or do you want some more time to review? No, I approved it right now. Oh, you did? Good, okay. And I also added it in the document, but I'm not sure it doesn't reflect the changes on your side here. Is this not synchronized between users? It should be synchronized between users, but maybe there's a delay, don't know. Okay. All right, so we're given that we've got four out of five board members approval. I think we're good to merge that as soon as, in fact, it can be merged now. Kevin, if you have permission, you have authority to merge it, you're welcome to go ahead and merge it. It's got enough approvals now. We still have more topics to resolve there in terms of we had an open question, what license should be used for library plugins like the Apache HTTP Components library, like the JSON library, various. And that's, I think, a question we just have to answer by way of policy. And I've still got the assignment to go looking at other projects and see how they do it to see if we can use some of their knowledge. Anything else on that topic? I don't know if it's really that important to do that last bullet point anymore now that we've allowed public domain, because I don't think there's a need for, there's no need for us to accept any more licenses that we're currently accepting if we are including OSI and public domain as official accepted licenses. So I don't see a practical need to work on that last bullet point anymore. There's no request for us to post something that is using a non-public domain, non-OSI license. Okay, so let me, I think there may be some old email in the board mailing list that I need to review to check that, but I like the way you're thinking, Basel. Let me do the double check to be sure that I need to review that old email to see if the licenses that are mentioned there are in that set or if there's some additional thing that we need to discuss here. But I like that, thanks very much. Good insight. We may not need this. That's great, because that would then give us that we're really done with this action item because there isn't more change needed than just to accept public domain licenses and that's been approved. Yeah, I mean, if there is any other license, I'd be curious to know what the demand is because we've already covered almost everything here. We have a clear policy about closed source which we reject that and for everything else, I think we've covered all the practical use cases. So if there's an additional use case that's not covered by this, I'd be interested in learning about what it is. Great, thank you. All right, thanks very much. Anything else on the license policy topic? Well, yeah, I guess the same question applies to the library plugins. Do we care about answering this question or do we just table that as well? How do you think it is to get an answer to this? And I'm not sure that it's relevant at all because in most of the wrapped libraries, there is already a license applicable. I don't know of many of them that don't have this. So for me, I'm not worried about an answer to that. Well, yeah, I mean, I think there's some inconsistency in what we're doing right now. Some of them follow point one, some follow point two. Oh, I mean, I guess I'm wondering why we keep on postponing this question. I mean, it should be an easy question to, I mean, if we care about answering it, we should be able to answer it in like two weeks by like thinking about it and then voting about it. And if we don't care about it, then we should just remove it from the agenda. But to keep it on the agenda and to never come to a decision seems strange to me. Fair point. How about let's set ourselves an expiration and close this thing next meeting and intent is to close it one way or the other. Is there some research that needs to be done about this or is this, I think it's more of like a subjective question. That's why there's no, you know, there's no right or wrong answer. It's just a matter of what do we prefer as a group? So, you know, if we have an intention to vote on it next week or whatever, not next week, but next meeting or the meeting after that, you know, maybe that's something that the members of this meeting could just think about and decide what their preference is. Right. There's really no wrong answer to this. Fair enough. I think let's note to choose the alternative next meeting and close the action item. Did you have any research that you think would help influence your preference one way or another if you knew some facts that you could don't currently know? On that one, absolutely not. The license used for a library plugin, it's me making an arbitrary decision, I think. Sure. Anything else on that topic? Yeah, I mean, I've actually gotten re-licensed some of these library plugins in the past to suit my preference. And while I was doing that, I discovered that some people have a different preference. So, I could, you know, based on what we decide, I could go and try to re-license some of the most. I could just try to homogenize some of this stuff. Like the ones that I maintain, I choose bullet point one. And I think in some cases, I've actually gone and proposed re-licensing toward that of things that didn't match my preference. But if we decide on number two, then I could go and change my own library plugins to match number two, to re-license them as MIT. So, what's more important to me is that we're consistent, not that we have any particular decision because the inconsistency seems a little strange to me. That's all. Now, is this specific one a case where we should, as I think about it, I'm a little surprised that we could do anything except this one, except the second one, or the license of the wrap, use the last license of the wrapped library because I assume that that's the governing thing in a library plugin. Do we need it? There's no rules about it. I mean, just like with Jenkins Core, we have a different license from our dependencies. You could make the same argument about a library plugin being the only original code of ours is basically the manifest. And maybe we have some tests that are associated with it. In some cases we have abstraction layers like for the HTTP libraries, but essentially for these wrapped libraries, our original code is close to zero. So it seems a little bit silly that we would put an MIT license on our very small original code while wrapping a much bigger, it's kind of like the tip of the iceberg where the bottom of the iceberg is most of it and that's under a different license. So to me it seems a little bit silly, but it is legitimate. I mean, even a small wrapper could be licensed separately if we choose to because that manifest is our own code. It's not theirs. Got it. Okay, so it's not a matter of our license on the wrapper somehow trampling there's any more than our license of MIT license of Jenkins Core tramples any of its dependencies. It does not. That's right. Got it. Thank you. All right, so we bring this to a closure at our next meeting. Thanks. Anything else on the topic? Okay, next then, community update. Kevin, you wanna share with us briefly the Jenkins contributor spotlight. Yeah, yeah. So everything's going really well at this point. The site's been live now for almost two full weeks or just about actually just two weeks. We've got Alex Orrell is gonna be published on Wednesday. That's the next contributor spotlight. Christopher will be the last one this month on December 27th and then Uli's gonna be the first of the new year. So everything's been submitted. Everything's been getting reviewed. Thank you so much to everyone for the collaboration and all their help and their reviews. Yeah, everything's, I just appreciate everyone's help. Uli, thank you for being next up in line or in the queue. And yeah, everything's going well. Thanks. Any questions to Kevin? Okay, next topic then is the Artifactory bandwidth reduction project. So in November, we used 20 terabytes of bandwidth from repo.jankenci.org and one third of that approximately was cached artifacts that could have been obtained from Apache Maven Central. JFrogs asked us to remove the cached artifacts to reduce their costs hosting us. That makes sense. So we did a brown out last week on Wednesday and the core build passed, the repository permissions update or failed because of a missing library due to a misconfiguration on the test and then 200 plus, 230 plus plugins all passed just fine. We found several key failures, right? This JIRA integration jar, we know how to fix it. Crowd two, this one we've realized we need to suspend the distribution of this plugin. It's got a closed source dependency and we don't do those. There were some failures due to outdated tooling that really pretty easy to fix that kind of failure. In general, my sense is this brown out was a great success. I've given thought to it and come to the conclusion I think we ought to go production this week. Now, Buzzel and I had had this conversation earlier and at that time I was hesitant but I think it's worth us thinking let's get the costs lowered as quickly as we can so that JFrog isn't paying so much money for so long. Other opinions, other ideas in terms of how rapidly we could alternately do another brown out and then next week, go production, opinions. Well, the Maven public repository is still set to the wrong permissions. So that needs to be fixed before we go public and it's easy to test because you can just open that up in your web browser and see if it's asking for a password or if it's accessible. So that was the only blocker that I had from a testing point of view. We don't need a brown out to test that. We just need to make the permissions change and test that it's visible. So I would be a favor of moving forward without a second brown out as long as that test is performed. Great, okay, good. And when you said, I think you mean the Atlassian public repository or did you say, I heard Maven public? Right, there were two Atlassian repositories that we had considered mirroring. One was called by them called Maven public and one was called by them Atlassian Maven external. And so we decided not to mirror the second one because it contains proprietary jars that we don't want but we did decide to mirror the first one which contains open source Atlassian jars. So that, and yeah, that's the only action item there I think is to set that permission so that it's publicly accessible from our Artifactory server. Excellent, good. All right, any concerns from others? Okay, so I'll draft a message to the Jenkins developer list and we'll work with the infrastructure team probably tomorrow during their info team meeting to confirm that Friday is a workable day for them to make the transition. All right, next topic then is a no change topic. Sorry to bring it again, just Java 11, 17 and 21, I've still got work to do on the Jenkins enhancement proposal. I hope to get to that this week. The things are about what does it take to add a Java version, detailed lists, what does it take to make it the recommended version and then the big one for me right now is what does it take to drop a Java version? Any concerns or comments there? Okay, so the board and officer elections, I think I've captured everything here that Alex shared in his email so Basel's been added to all the correct locations, Oleg's been removed from all the correct locations, anything that I missed there or thing that I need to change in the notes? All right, then next is we've got some board level things that happened in the bandwidth reduction project. We've, we have completed the suspension of the crowd to plug in because it was using closed source dependencies. So it's been run through the process, we notified the developers, the developers said, yes, sorry, it is in fact using closed source dependencies and we don't have the time to switch it and this particular service, at least part of it, ends in September, in February of 2024. And with that, that set of changes, they said the maintainers chose to archive the repository and the plugin has been dropped from distribution. The Confluence publisher plugin is also using closed source dependencies but that message only went out just yesterday to those maintainers. So we're gonna give it a little bit of time to let them see if they've got any response for it. Any questions on that one? Okay, next one is one where I'm looking for opinions. We had an episode on Wednesday, May 6th where a user applied bulk operations to 900 plus Jenkins issues. They assigned unsorted to the issue. They, to those 900 plus issues, they put many, many labels on them, several other changes. The question to the board here is, which of the recovery alternatives do we want to take? We could, I missed putting one in here, let me put it in, do nothing. Is the, let's see, where are we? We could ask Linux foundation to restore from backup prior and admit that we lose all the changes since then or we could attempt to manually reverse the most obvious things and accept that it's imperfect. Comments, Basil, I think you'd said you would be okay with restore from backup given how long it's been. So we're now five days later, would you still be okay with restore from backup or different opinion and Uli, your opinion as well and Bruno, I'd like to hear each of you as well. And Kevin. Yeah, well, I want to restore from backup because a lot of changes were removed from epics and they could be, we basically lose, the epics won't be completed anymore if we don't relink the changes back to the epics. So I just don't want to lose, I don't want to lose these issues because they were unlinked from their epics and they don't see any way to restore that link other than restoring it from a backup. Good, all right, I hadn't thought of the epics. Thank you, that makes sense. I was thinking of much simpler changes. So we lose epic links. Oh, no, we restore damaged epic links with the restore from backup. Great. Uli. Sorry. I think, yeah, at least my issues are not so, you're really disturbed. So it's just some links which are not offending. So which problems cause the issues? Because in my issues, I think there were some tags added and it is not really important for me. Buzzel, you wanted, I think, well, Buzzel, you can probably describe better than I can how you use epics and how they help. The changes that I noticed were things being unassigned, which I don't care about assignments, a bunch of labels are added, which I can, I don't care about, it's easy to reverse the label changes. But the changes that seemed the most destructive to me were when basically the type of these epics was changed from epic to bug, which destroys the link from the epic to all of its children. So then when you go to view all the work that was done on a project, we can't find all the subtasks anymore. So that kind of hurts from a project management point of view because we've now lost the relationship between tasks and projects for a lot of projects that we're tampered with. So if you change back from bug to epic, those links don't magically come back. No, they don't, unfortunately. Okay, good, all right. Bruno, any further comments from you or Kevin from you? No, I would go with backup restoration, of course, to get the epics back. Kevin? Same, yeah. The only issues I saw that were affected were related to Java documentation and yeah, those things are long over. So I think it makes sense to just put everything back the way it was. Great, all right, so I'll take the action item to mark request restore from backup by the Linux foundation. And I'll keep that topic. Thank you, thanks very much, good insights. Okay, and this next one I had captured, we've already discussed this one, I think, in depth from the earlier section on action items. Are there any things additional that we need to need to discuss here, Basel, in terms of attribution request? Well, I think we actually discussed the levels previously today. I just talked about the fact that there were levels, but in this bullet point, you're trying to get people's opinions on the two concrete proposals of levels in this meeting. So we haven't talked about that yet. Great, okay, so then the ideas here where Basel had initially proposed a series of terms to categorize things. And I came back with an alternative of using three Olympic metal colors and then a top one for anchor and a bottom one for mirror. And I'm open. I was hesitant to use the word partner because I've had some negative feedback in the past when we dared to use the word partner with regard to Jenkins because some people take that as implying a business level relationship. Opinions from others on preferences one way or the other on the levels? Yeah, I think the three, I mean, the original, what is it? One, two, three, four, the original six levels seems to be too much given, you know, we don't have that many sponsors that we need that many levels. The three levels for the Olympic analogy kind of makes sense to fit the bulk of our sponsors with the anchor level being reserved for an outsized sponsor, some sponsor that is far above the others in terms of amount of contribution. And mirrors also kind of makes sense to me as being a level below bronze because it's really, while it's appreciated, it's less of a financial contribution than the others. So it's kind of seems worth switching analogies. And one of the other benefits of mirror as a separate category is that these mirrors often don't have logos. So unlike the other levels that usually have logos, if we keep mirror as a separate level, that can just be text links rather than images. So that would look better visually on the page as well. Thank you. So I think then are we, would we be okay? That's you Uli, I see we may have lost your video if you're still there. I'm interested, would you be okay? Given that we've got through, I guess we've only got three board members. Maybe we ask for a vote separately so that we get Alexander's and we give Kosuke the option to weigh in if he would like. So what I'd like to- We can save the voting until I've come up with the final list who belongs in each level. And you can actually look at the sponsors page visually to see what you think of it. Cause this is more of a, this is more of like a step along the way to building that page. But yeah, if there were some negative feedback early on, I could switch direction without wasting a lot of time. But it does, so I guess the main question that I would have is, is there anything obviously wrong with this or should I proceed with drafting the page and then we can look at it later? I like that, yeah. I don't see anything obviously wrong with it. Do any others on the meeting have any clear objections or reasons why we shouldn't proceed with these ideas? Okay, then let's go ahead. We'll hold on the vote. I like the idea of being able to look at working prototype. That feels really healthy, good. Next topic then is social media status, posting status. And our social media volume has been down the last two weeks compared to the previous two weeks. The crucial thing there is we need to encourage contributors to propose technical social media items to share. So when you see something interesting, you can propose to share it through advocacy and outreach. On the Azure credits donation, Damian DePortal has started consuming the Azure donation. So congratulations in the month of November, we spent at least our first dollar of the donated Microsoft funds. And that's a good sign. Any other topics before we close for today? All right, thanks everyone. Thanks for your time. Recording will be available 24 hours or so.