 Welcome everyone. This is the 6th of February 2023. This is Jenkins governance board meeting. Thanks very much for being here. So items on the agenda today I've got news action items. And then late additions to the agenda sorry they didn't get into the published draft Jira license changes. Google summer of code and then highlights from community activity and there Alex I was hoping you'd be willing to talk to your experience at at Fosdom. And then I've got a topic on Artifactory, any other topics that need to be on our agenda today. Okay. All right, and let's go through. So news items. Two days from now Jenkins 2.375.3 will release release candidates available for testing encouraged everything looks right the the change log has been merged. Alex, I believe you are the release lead is that correct. Yep, that's correct. Great. All right. Next item is that the next LTS baseline will be 2.387.1 it will release March the eighth release lead not yet determined as far as I understand. And the January 2023 newsletter has is in preparation right now. I believe the poll request or a draft poll request has been started, and we can take off the Fosdom news we'll talk about it a little later, any other news items that should be on on the list. Okay, next topic then action items. Alex, you want to share with us on active community SIG and board members, being sure that we have the correct person to own all the projects SIG and community mailing lists. That's actually a leftover topic from the last. Sorry. Yeah, you wanted to get rid of that one because that is done. And yeah. Got it. Thank you. Thank you. My apologies. Thanks very much. Election badges not done. No progress. Easy CLA as far as I know no progress. Empty and agenda entry worked this time. I did it will keep it there for now. No requests for the converging to a single concept of working groups, not done yet, but I'm back contributing to docs a little so there's hope for that. Next topic was a proposal to retire the Chinese Jenkins site. I had another reason that needed, I needed to talk to Rick and so I asked Rick the same question. And Rick replied with a recommendation that we redirect the Chinese pages to their English equivalents. I take that as his implicit agreement that we should go ahead and end the Chinese site we're also getting new bug reports due to the Chinese documentation being out of date for example we got a bug report recently that said, Hey, I can't do a Linux install, and they included the Linux install instructions that are available on the Chinese website. Two years out of date, and we've had significant changes to our install process that are just not reflected there I think that's a disservice to these Chinese readers for them to see something in Chinese that's, that's two years out of date. So the proposal was let's put an action item on our docs officer Kevin Martins to raise a help desk ticket to to replace the Chinese web pages docs paid pages with redirects to English. Any objections to that as a proposal. No, I think it sounds great. No, this is one where I'm not sure I should call for a vote or not so it did it felt like this is this is just a good healthy thing for us to do I don't think that the board has to. And if there were some if someone brought back the Chinese documentation or fresh translation we can always bring it back it's not that this is never never to be done again. Okay, good. Alright. Last item was the docs, the governance meeting notes. Sorry, no progress for me on this one and I still have the action to check with what the response was from infra team and bring it back to our group. Any questions or items on the action items. Okay, next topic then. The license changes will affect the Jenkins project. So the I was reminded of this when Andrew Grimberg of the Linux Foundation replied to a support ticket I raised, asking that they refresh the license he reminded. And we've known about this for a year or two that effective February of 2024. And Lassian no longer will have their standard product available in a hosted solution, it's all going to Atlassian cloud. Now they do have a hosted solution called Jira data center, but that's not the license we have. And so the discussions have started the security team, because of their tooling and the, the greater capabilities that are available in Jira would prefer to remain with Jira. But there are some barriers to us preferring to remain to us remaining with Jira that we've got to work out with Atlassian. The best would be if we can persuade Atlassian to give us a Jira data center license, then Linux Foundation continues to host us. It looks no change to us they just upgraded our license and we're done. If we can't get a Jira data center license from them and have to go to Atlassian cloud. That means we have to live in the limitations of Atlassian cloud. Those limitations include not more than 35,000 registered users. All registered users must log in through an Atlassian account. And then I think there are other barriers as well because we'd also have to do a data mic, you know, data copy to their, their destination. So my concern is our, my strong preference is to keep us on Jira, but it needs that we need to persuade them that they should donate this license to us. Any concerns or comments there on this Jira license change that's coming. I think every project needs to make this move, even in a lot of companies here in Germany need to take another license so I think it's, we can't do anything against it so we need to go the way if they give us a license. And if not here, we should consider moving away from Jira or using the cloud, but I think we still have a little bit of time to decide. Right, agreed. Alex your comment. Yeah, I agree with only here. I think we don't need to hope for the worst case here. Like I said, 2024 that is still a year away, but like giving us some spare time to consider something and reach out to them to get us the license. But yeah, but I also think we can't get rid of Jira because the entire security workflow is so embedded with Jira. We can't just go to get up or any other alternative that easily. Agreed. I think I think they're well and and bozzles bozzles provided a number of other points about why Jira is a much richer way of managing issues in this developer mailing list. He notes, notes that there are capabilities in Jira that the most recent GitHub issues just don't represent those things. And that that will be a sacrifice if we have to do without those. So good. Okay, so I'm going to continue. I'll plan to report status on this periodically. How can we make the most, how can we make the most compelling argument for them to give us that license that we need. Is it because there are they giving us a license already for the current hosted installation. They are different one. Yeah, they're giving us a license already for the current hosted one. The, the crucial things that are most compelling to me, and that I thought were persuasive and that I included in my last email to Chrissy was that they've got an upper bound of 30,000 on their Jira instances and we have well over 100,000 on ours. We've already made that point to them. Right. That was my that was basically what I was trying to get at. So, yeah, that was convincing argument we could make. Well, and I think there may be more arguments beyond that I will certainly reiterate that one to Chrissy again as as she and I go through these discussions, but licensing, then the, the using our own LDAP is for us, somewhat of a win because we don't have to do a transition of 100,000 or even 10% of that 10,000 users to get them in addition to having their existing Jenkins account and the GitHub account they use they would now also have to have a bit and at last year and that that feels like that would be a significant loss to us. It's much healthier if we can persuade them to let us keep continue bringing our own authentication but in order to bring our own authentication. We have to run our own server which means Jira data center, which means Linux Foundation. It's very convincing to me. I'd be surprised if they would push back about that, because even if they want people to migrate to their, their hosted solution would be hard to argue against those points that preclude a hosted solution. And that that's my hope now Andrew Andrew Grimberg of the Linux Foundation seems ready and willing to continue hosting us so long as they can get the data center license he indicated to me that they have one or more other of their solutions that is using a data center license, but they have to be granted to the project right so so they've it's got to be granted by Atlassian it's not something we can just get magically anything else on the Jira license change. Great. Great. Thank you. Next topic was Google summer of code. And this one I brought to governance board just for your awareness. Our application is due tomorrow. Alyssa Tong, John Mark Mason, and Chris Stern are the org admins for Google summer of code in the Jenkins project. They're preparing that that application. Bruno Verrachton is also helping there with organization admin. Moving forward to that application, we're expecting to be submitted today because final deadline is tomorrow. And it does change one thing I've realized in preparing for Google summer of code that I can't reasonably lead the she code Africa contribute on 2023 like I've done in 2022 and 2021. And I think we should just accept I've accepted that we won't be doing she called Africa contribute on in 2023 because we want to do Google summer of code very well. I'm open to other opinions other ideas or if others want to volunteer. My experience was, it's a good experience it's a low cost experience for the Jenkins project cloud bees donates about $6,000 and and then that funds six or seven new contributors from Africa for a period of four weeks. However, in terms of its actual impact on the Jenkins project it's significantly less than the impact of Google summer of code. So I'm pulling back and I'm going to propose we not run it at all this year. Any objections from others. Okay, great. And Jenkins project at Fosdom. Alex, I wanted to hear from you how was the experience. I understand that you were there and that you were at the booth, and etc. I have pictures as evidence of that. Yeah, I was at the booth at least at Saturday. And the booth was pretty busy and active as already noted down. People were much interested in Jenkins, ranging from people who are using it for decades and newbies around. I don't know, couple of years and ranging to possible G sox students. So market conversations with. So yeah, it was pretty interesting experience given so much people were actually interested in Jenkins, ranging from so many different backgrounds and yeah. Thank you. Thanks very, very much. So I am curious, how long is the travel from where you live to Brussels is that are we talking did you have to do four or six hours of travel to get there. Yeah, it was just for our train ride. So it was not that far away for me. That's wonderful. Thank you. Any other highlights you want to share. I had the Saturday at the booth the Sunday I left for the others because it's a pretty was a pretty stressful day and I also wanted to attend a few talks and meet other people. But yeah, the Jenkins community dinner on Saturday evening was pretty well visited I would say the people you have on the list where they're Stefan speaker was there. Oh, good. Okay, Stefan was there. Yeah, with a couple of his fellows. I had a chat with him. Oh yeah, Stefan was also there just added them to his list. And Carlos Sanchez was there and a few other familiar faces. Well that's great. Thank you. Thanks very much. All right. Anything else on Fosdom or any any comments from others. The next topic was in community news we've gotten a project ongoing with JFrog to reduce the bandwidth use from our artifact repository. They've been providing us with log files. We've been doing analysis of those log files and the analysis has detected some quite heavy users that we've unnecessarily heavy users that we've been actively reaching out trying to contact them. We were successful on one of them. The other one is a machine in China that we're still trying to find a way to either block it or locate the owner of the machine so that they'll stop requesting the same war files over and over and over again. And that's as one of the other improvements. I really mirror down into portal and Stefan Merrill have just deployed last week and artifact caching proxy for CI dot Jenkins dot aisle. And that proxy right now is just doing plug in builds. Other other projects like the bill of materials are coming. And then they've recommended JFrog has recommended some permission changes that are actively under development they've set a goal for us to do a goal to do the first brown out test drive of the new permissions in mid February, we're behind schedule. We're behind schedule on that because of these other changes that were more that were more high impact and had a better chance of doing an immediate reduction of bandwidth use. So that brown out, and the plan test will be announced in the future. What it's really doing is this thing is changing the permission model so that instead of everything on repo being public and readable by anonymous. It would only allow the artifacts that the Jenkins projects creates to be readable by anonymous and would require authentication to read the other parts of the cash things like all the components that are cash from Maven repo one or the components that are cash from the eclipse J get repository. So that's, that's yet to come. Any questions on that one. Thanks for me to do any more analysis on the logs from JFrog, or do we think we have enough action items with the existing analysis that we don't need anymore. Any more combing through these, these logs from JFrog. I think, I think we, I would like to see this week's logs. They should be coming to us today or tomorrow, and I'll go through those Basel rather than take your time to do it, but after I've been through them I may ask you to do one more look just because I suspect the next level down we're going to have to do that analysis and look for things that will point us to JFrogs recommendation for these permissions changes would not have affected any of the things that we found in our initial analysis but we expect there will be cases that are found by that. So, and if there aren't that would be a reason to push back against the recommendation. Exactly. I good good point a very good point that if our log analysis says, no, the vast majority of the usage won't be changed by these permission changes. Then, then there's not much point in making the permission changes. Yeah, good, very good. So, are you good would you would you get in contact with me when you want me to analyze the logs again or should I be putting some calendar. Yeah, that's a good one. Let me mark. How about if we'll put it as mark contact Basel when new logs are available for analysis. Okay. Does that work okay for you Basel. Okay, great. Yeah, that way I won't get in your way. Super. And well, just highlight is the problem that we are writing too many artifacts or that too many people are reading too many. I think it's the latter because they're complaining about too much bandwidth being consumed from the downloads. Yeah, so the problem is outbound bandwidth and you asked an interesting question, only because it's the same question we asked we were a little concerned, we write a lot of incrementals. Are you really frustrated at how many incrementals we write and their answer was not in the least. That's not a problem at all keep writing. So I was, I was really pleased because we could certainly expire the incrementals after a year or you know we could, we could set expiry and they said no don't bother. That's yes you could do that but really don't bother storage is not not that expensive. So, what did that address your question earlier was there. This was exactly the question because we have a lot of incrementals and I'm not sure if we really need so many or if we should keep everything. We certainly could expire. Well, every build of every plug in with incrementals enabled pushes an incremental or every build that's current to tip current to the tip of the master branch will push an incremental and therefore we're storing lots and lots of those but but their answer really was no that's not the big issue the big issue is outbound bandwidth. So the issue we've had with the Jenkins war files is, you know downloading every single war file from the very first release of Jenkins, all the way up to the latest release, which is a large amount and each one is about 100 megabytes. So, it's a lot of download bandwidth. Yeah, and that one, that one, that's just got to be some kind of a program gone awry. It's, you know whether it's something's wrong there. We're talking about downloads of Jenkins 1.324 something, you know, from eight or nine years ago, happening hundreds of times a day. So, that's that's what we're trying to get to the bottom of. Not exactly. So, if you have contacts in China that could help me find someone at a hosting provider I would love to hear about it. I'm trying to use every contact I have, and thus far have not, have not reached an end point yet that will help us solve that any any other topics for today's governance meeting. All right. Thanks everyone thanks very much for your time. Recording will be available in 24 hours or.