 Welcome everyone. It's September 5th, 2022. This is the Jenkins governance board meeting. Topics I've got on the, I see on the agenda include news. Oops, oops, and I've got a bad indentation here. Sorry, let's fix this indentation mistake. Plug in adoption process improvements. There we go. All right, upcoming elections, CDF topics, if any, Jenkins IO website improvements and forums and community topics. Any other items that need to go on to the agenda. Okay, then let's go ahead. So in terms of news, the LTS comes out Wednesday. Thanks to so many people who've done so much to get us ready for this, that will be the release that the first long-term support release that no longer includes Java 8 support. Thanks to Chris Stern as the release lead. And thanks very much to Basel and to others who've done an amazing amount of work to get it there. There will be a CDF blog post coordinated with or that will happen on the same day. And of course, the change log, the upgrade guide, et cetera on Jenkins.io. Any questions on the upcoming long-term support release? Okay, next topic then is action items. These still no further progress to report. The Linux Foundation funds transfers have started. Kara and Alyssa definitely made progress, but I hadn't seen two weeks ago any progress there and not sure what the current state is. Let's do a quick look and see if I've still got access. Ah, I think that is an increase. Good, so the funds may actually have arrived now. Very good. All right. Thanks, that one is resolved. Hey, Docs signaling this transition not started yet probably won't happen until October at the earliest, possibly November. A blog post for contributor summit. I'm prone to just drop it given my inability to get this one done. We've got so many other things happening. Any objections if I drop this one? Didn't, wasn't there just a post about something? There's a new, the next contributor summit will be the contributor summit in September and that definitely has lots of work going on. Oh, yeah, that's right. Yeah, no, I'm okay with dropping it. Great, all right. And I've still got the action item to request full access to the CDF Zoom account. This is one of two different paths we could take, right? Well, since I'm assuming based on our previous conversation 100% of the boards here wants to go with the Google group method. I think we should go with the Google group method. Okay, good. All right. So Mark, ask Michelle to add that group. I should make a group as an action item. Oh yes, okay. Gavin, make the group. Great. Thanks, Gavin. Can do. All right. That's the, all the action items I'm aware of. Next topic was plugin adoption process clarifications. There are two pull requests open. One is this clarification submitted by Tim Jacome to update the document to state what I think is a natural way to do things. If a plugin has no maintainers listed, then it can be adopted in an accelerated fashion. We don't have to wait two weeks for a timeout. There's no, we need to wait two weeks for a timeout for a response from non-existent maintainers. Yeah, I think this is what we've been kind of unofficially doing, but I kind of want to see things written down once we have it started. So I'm on board. Right. Me too. I'm plus one for it. Yeah, this, this isn't only natural because otherwise that timeout would be, I mean, it's a pointless timeout because no one can make it any shorter than what it is. But I mean, in general, it's a good idea to codify this implicit knowledge because then we can refer to it later if we, if we want to make changes to it. So I'm very much in favor of codifying these implicit processes. The only, the only piece of feedback that I would give is as we codify them, it would be nice to include the rationale for each piece that we codify because often if you're going back in the future and looking back at these decisions, we'll sometimes want to ask our past selves, not only what we codified, but why we codified it, which is going to be obvious to us today while we're making these decisions. Like, you know, for me, it's obvious at least. Like, yeah, this is obvious because otherwise the timeout would just always be two weeks and there's no way to decrease it if there's zero maintainers. So I mean, in this case, it's fairly obvious, but in other cases, the reasoning might be lost to the future versions of ourselves. So that's really my only piece of feedback is codify more things and include the reason. And even if we don't do it in the document itself, making sure that the PR that included it is documented up to, yeah. Yeah, well, so Basel, to be sure I understand because I think this text is describing that, but it would require that the reader has to do a get history dig, whereas I thought what you were suggesting is we would prefer to put it actually in the text of itself with the rationale. Yeah, I mean, I don't feel strongly about where the rationale lives. Ideally, I think it would be in the text itself because that kind of forces the rationale to be summarized into the most succinct form possible, but I'm not fussy about where we put it. Like, if it's in a big discussion in the pull request, that could definitely be good enough as long as it's captured somewhere. Great, at the very least in the pull request better in the documentation. Right, okay. So Bruno, any comments from you on the topic? No, no, no, thank you. Okay, all right, so given that we've got approval from Vodik and from me, we've got enough approvals here, any objection if I go ahead and merge this? Let's do the other one first and then come back to this one just in case someone wants to come back to it. All right. Because we only really announced it like 10 minutes ago. Correct, fair enough, good. So let's go to the next one, a proposal that what we have right now is code owners on jankins.io and governance documents are actually listed with governance board as code owners. This document, however, that Tim had just proposed the pull request to is actually not in the governance tree and therefore was not listed under governance responsibility for code reviews. So what Gavin's proposing here is let's put that one under the responsibility of the governance board as well because it is fundamentally governance process. I should I be alarmed that the code owners contains errors? Did you find an error? Yes, you should be. There's a big yellow banner in the Senator's screen. Oh, that, yeah, good question. I hadn't, okay, unknown owner online 29, okay. So we need to fix that. Yes, but not because of this. Right, this is not exactly, right. So comments, concerns? I think it makes sense. But the only question I had is how was, how has this worked in the past for comparison? I mean, is this another case of codifying what is already a de facto policy? Or is this a change in policy? It seems to me that it's just more existing de facto policy and we're just codifying it. So that seems fine. Well, the default editor is copy editors. So I don't know if necessarily there was a previous one, but that plugin adoption process and it has not really been changed in like 10 years. So I don't know if there's a previous version of it too. But I don't think copy editors should be really the one approving changes to this document. So I don't know if board is the right choice, but I don't see it a better choice. And I definitely don't think it's copy editors. Particularly since copy editors right now, if I recall correctly is at most maybe three people. Tim Jacome, me and maybe one or two others. So it's not, I think declaring it explicitly as Jenkins board makes sense to me. I think Basel, to your point, it is largely a codification of existing practice in that we don't make changes to this document without lots of discussion. I could do a quick check, but I think the historical evidence will show that changes to the document are carefully considered and discussed before we ever bring them out and assigning them the code owners as Jenkins board is a good way to make that explicit. I also don't think there's been changes in a while. Great, okay. So then this one, I think makes sense. We go ahead and say, yes, we're going to do it. So I'm going to merge it. Sounds good. Okay. Now, I'm okay with the other one being merged. I just wanted to give people an extra five or 10 minutes to speak up, which nobody said anything, so. Great, so let's- I can't really imagine anyone saying anything either. Okay, and we've got approvals from, I'm on the board, therefore I'm a valid approver to do that. We've discussed it here. And with the security officer as well, I feel pretty comfortable. I'm going to go ahead and merge it. Sounds good. All right, thanks. Okay, so merged and merged. I mean, the order they were merged, great. All right. Anything else on plugin adoption process? I do still want to codify GitHub access into that stuff, but that's not really, yeah. Too much manual process right now. Are you referring to the fact that the people with GitHub write access are frequently different from the list of people that's in RPU? No, politically. Right now, when a, when, let's say, for example, a plugin is adopted, one of the hosting members still has to go to the bot, the city on IRC and run a bunch of manual commands to give someone GitHub access. And there are problems with people who have been manually updating that list. And then when they come to make a change to RPU, we don't know who they are, so we can't approve or deny that request. Yeah, so. Yeah, and conversely, the problem that I've had is when I remove myself from RPU, I don't get removed from the GitHub side. Yeah. So I frequently remove myself, but I think a lot of people forget to do that. So they end up not having RPU upload permission start a factory, but still retaining their GitHub write access, which is a bit inconsistent. Yeah, and we've had a number of people that need to recover because someone's left the companies, but they have get access but not publish access. Yeah, I mean, I think in the long term, my vision for this would be to essentially write a script that would sync the GitHub access in both directions with the artifactory access. In other words, if you've lost artifactory access, you should also lose GitHub write access and vice versa. But I think that after writing the script would be one thing. I mean, someone could do that in an afternoon, but the more difficult piece would be doing a dry run and seeing what that would really mean in practice because I think it could cause a lot of hiccups if we're not very careful about how we roll it out. So to me, that would be the big part of that effort was just to like a dry run it and make sure everyone's okay with it. The actual big effort is that artifactory is LDAP and GitHub is GitHub. And so we have no way to map the two, which is what the original thread was talking about. And yeah, so I have to go back and finish the proposal and the discussion, but my plan was to only make initial version of the script to only be additive and not subtracted. Don't take away access, it's not codified yet. And then in a month or two months from now, then start looking at removing access, but just make it so that it adds. So it's very clear this is how you do it. Yeah, I think removing access is helpful as well. I mean, as a second stage of this because there are a lot of people that get pinged unnecessarily because they still have right access even though they're no longer maintaining something. And it can send mixed messages to users when they approve a PR and they've got the green check mark even though they're not actively maintaining the plugin anymore. Whereas if we remove their right access at the same time as removing artifactory upload permissions, then that's not only logically consistent but it also kind of sends a unified message to outside contributors, which I think is helpful. But yeah, like you said, that's a much bigger project. So. Right. Great. All right, anything else on plugin adoption process clarifications? Nope. Okay, next topic, upcoming elections. So our annual elections of officers and board members are scheduled for or slated for December. Gavin and Evelina are both up for reelection. We had the question last time, who's running it? I still have the action item. Sorry, I failed to do it last time. I need to mark to confirm with. It's about four timelines down. Oh, is that where it is? Oh, yes. Thank you. Don't need to retype it. Thanks Gavin. So this one, yes, we should do is what is the other way we're doing it? Oh, yes, right. Good. So tomorrow's info meeting and that'll be the first day that Damien's back in the office. So good, good time to talk to him. What a nice surprise. Yes, welcome back. Here's a, here's a task. Okay, I assume that we're still good with let's use the same processes last year, register through community.jankins.io, go through the system at Cornell. Yep. Great. Usually we reserve CDF topics for Oleg with Oleg not here. I don't, I guess I've got one CDF topic, a blog post coming on Wednesday for Jenkins 2.361.1 written by Kevin Martins with help and reviews from Basel and from a number of others highlighting some of the history of Jenkins and some of the ways that it's been evolving over time, et cetera. That's a CDF blog post, by the way. Any other CDF topics that are of concern there? I guess I should highlight one that is JFrog is working with the Jenkins infra team to reduce data transfer costs for our repository server. So I was thinking about that today. The Helm chart installs plugins every time it boots up. Is the installing plugins part of Artifactory or something that we're hosting externally? That's something we're hosting externally. I don't like the Helm chart does it, but I was just wondering if this was related. Right, and I agree with you. I don't like the way it does that either, but yeah, that's using only Jenkins mirrors, not using Artifactory. I don't think there's anything to discuss here, but I'd like to mention during this meeting a big thank you to the Linux Foundation for restoring the JIRA server last week when it went down. That was much appreciated from our side. Yeah, good point. I was looking at the hosting. We've only had three outages, only three outages in eight plus months. Thanks to their hosting, that's a lot better than we used to do when we hosted ourselves dramatically better. So much appreciated. And more up to date, more secure. Yes, and much less likely to be vulnerable to security issues to be patched currently. Yeah, they're doing a much better job hosting it. It's great to have their services. Any other CDF topics? So next topic then is Jenkins.io website improvements. This one I have to show you a demonstration. Let's open the Jenkins website. And let's go to... I'm always impressed by the organization of your bookmarks. Well, if I didn't live and die with bookmarks, it would be a bad thing. All right, so first, thanks to Vihon Thora for his work on pipeline steps reference. Notice this little filter steps thing at the top. It used to be that when I wanted to find out how to do a checkout, I would do control F and search through this page. And it took me three or four false hits before I got to the place I wanted. Thanks to what Vihon did. Now I type checkout. There it is. Very nice. Next step, when I would press the checkout thing and open it, it would take a frighteningly long time to load because all sorts of content is hidden under these expandable elements. Well, thanks to what Vihon did, he's now separated those expandable elements out so that when I click on really large ones like this one, it gives me a hyperlink and takes me to a new page that is much smaller than the original page in mass, much easier for my web browser to process and much more comfortable for me to navigate. So special thanks to Vihon. It's been absolutely delightful at how well that work has gone. Reminds that contributions to open source are much more than just pure software. In this case, he did software that creates documentation. How long has that been live for? More than a day or two? This one has definitely been live for more than a day or two. Yeah, so it was- If you search in the top right, I can go look. But if you search and does that, I'm just worried that this is another page that they're just flooding our already broken search with more data. There are certainly several more pages. Yeah. But I don't think this has made it any worse. Okay. Okay, then. That's my concern is that I don't know how, I really kind of want to not use the Agolia doc search and just use Agolia itself and do it manually because then we can control it a lot better. But I don't know how they're mapping and stuff. And some of these pages are going to return results we don't care about for search. So I was just worried about that. But as you said, it doesn't look like that's the case. We're good. I didn't see it as dramatically worse. Although I see that our Agolia search, our doc search page search is getting worse and it's getting steadily worse. So we've still got the ticket on infra to find a way to fix that doc search definition so that it uses their new thing instead of the old thing we used before. And I do want to figure out more about that pipeline syntax generator because we have talks about putting some of the information probably this specific information into the plugin site. And I would love to start auto-linking in the forms as well. So if someone says a word checkout, it comes to this, well, the previous page. So yeah, those are other ones I want to, someone or I want to look into some point. Right, good. So there's also another move in place. We had attempted an initial look and feel improvement from a new contributor. Ended up that we had to pull it out, but we've got another pull request now from Jan Farachek and Tim Jacome has done some detailed checks on it. I haven't done detailed checks on it yet. There needs more. But if we look at this pull request, he's got a new look and feel, modularize more classes and increase the usage of CSS variables. And when we look at this in the preview, by the way, Gavin, thanks again for the preview. Seriously, seriously, thanks for the preview site. So if I show the preview, here's the preview with the new layout. And it still looks largely the same. He made some nice improvements in terms of the structure of the CSS itself. Needs more review though, because last time we went through this exercise we broke some things unexpectedly. Any questions or comments on either of those? I've noticed reading the blog posts that the typography has improved a lot recently as well. So I don't know if you call that out specifically, but it's been looking a lot better recently. Well, and that's something that Jan did earlier that was done a week or two ago. And I agree, it's a much more readable form now than it was before. It's much more readable, more comfortable. Yeah, one of my posts, exactly. Any other topics on? Oh, I muted. I would say if you want more reviews, because at the moment, I don't think anyone really gets pinged on those. Throw a thing on the dev list, possibly even the user's list, because this is not an normal Java topic. Because yeah, I can review like physically does the code look fine, but I'm not in any way a layout and CSS kind of person. So it looks fine to me. Right, I agree. It's a good suggestion, I will do that. That's a very good suggestion. It may even be a good advocacy one for getting new contributors into the non-Java space by throwing out a Twitter, LinkedIn post saying, you know, do you have an eye for layout? I want to get involved. This is a good thing to review. Yes, very good. Good suggestion. Thank you. Anything else on Jenkins.io? Okay, next topic then was forums and community topics. And I didn't have any particular hot ones this past week. Gavin, were there any that you wanted to flag? No, I'm going to take a quick look at the mail on this, but nothing comes to mind. Event contributor summary, did you mention that already? Good, yep. I think one of the boards is going to have to assign the GitHub project action stuff. Oh, right, right. That was actions four hours ago. Right, from Google Summer of Code, right? Yeah, I don't really have any. I mean, there are a couple, we saw an increase. Everyone's wanted, we see increases into the type of questions on the forum, but they don't seem to be yet related to a bug. They just seem to be all of a certain type come in one day and then they never get talked about again. Oh, there's the one, let's promote it this week, the Slack one. The blog post. Oh, right, right. The Slack blog post, right? On their Jenkins deployment and how they accelerate. Yes, good. That was from advocacy and outreach, wasn't it? Yeah, yeah, I got nothing else in the forums for the last couple of weeks. All right, any other topics that need to come to us? Oh, did you want to discuss? Well, I mean, maybe later we, someone's talking about on the on the dev list about merging and retiring old plugins that have replacements. I think it's going to be a bigger discussion that should continue to happen on the mail list. But there was a discussion about it. Good, OK, yes. I think that contributor said that they were interested in pursuing it further, but not for a couple more months. So yeah, but there was an idea. There was the. Topic brought up about what we're doing with older plugins that when their placement has been made. Right. And I don't think we're ready to codify that yet. If it's so to be sure I understand the context is this thing's I think the original conversation was around Kevin Martin's offering to adopt a plug in that seems to have a good successor already. There are certainly others like that, right? There's the multi multi branch project plug in that has multi branch. Is that what it is? That is declared deprecated and the preferred replacement is pipeline, but we certainly continue to still support and ship. Are we still ship that plug in? Even though we strongly recommend people. Hey, please use pipeline. It's much better suited for this. Is that the kind of topic and the kind of replacement that you're envisioning or is it something different? I just did. Topic was on the forums and I'm bringing it up. I don't know what we want to do about it yet, but I do think it's probably worth discussing in more detail. Although I feel bad that Kevin is going to get the brunt of this discussion because it's on his thread. I guess he's fine with it. I've talked about it. It definitely deserves its own thread. But I mean, the contributor identified a problem and did not really propose any solutions. And I think that's really the next step is to come up with some proposed solutions. I could envision a lot of different solutions to this. And obviously it would take time and effort to implement any solution if it's decided on. Because fundamentally, the problem of deprecating and migrating is a hard problem. If it was an easy problem, then we wouldn't be talking about this. I mean, it's also a perennial problem in Jenkins, in the Jenkins project. If you look at things like the Blue Ocean Docker image, which is a great example of something that is at the end of its life, but which needs a little more effort to formally deprecate and to help users migrate to the replacement. This kind of thing requires documentation, trainings, or there's a lot of dimensions to it. And it's fundamentally a difficult task. And there's reasons why a lot of people continue to use very old technology, just because that migration barrier can be difficult sometimes. So it's a worthy challenge, but also not a simple problem either. So definitely something that interests me a lot, because I've done a lot of these migrations over the years. And I have an appreciation for how much effort it takes, but also how worthwhile it can be once the entire community has migrated over. That enables us to innovate more quickly once we're all on the common ground, rather than being kind of bifurcated into all of these different usages. So something that I'm very passionate about, but also a lot of work. And I would definitely look forward to that contributor if in a couple of months they still have an interest in this. I think there's a lot we could do to come up with some solutions and try implementing some of them. Yeah, I mean, I have the same thing. I like to reduce, clean up, organize. But I tend to stick to less the people ones and more the code ones. So I went into the Jenkins IO and actually finally got rid of all the old HTML files, all the old markdown files, moved everything to ASCII Doc, that kind of thing. And I stick to it in that area, because it does involve a lot less people than get less involved. And I think in this nature of any open source project, you're going to have a lot of people that have a lot of opinions. And then things stall out. And I especially have a lot of trouble falling up when things stall up, especially when it's me stalling them up. Yeah, the people ones are a lot harder than the code ones. But they're also sometimes the most worthwhile ones if you do manage to succeed at them. And I found them very rewarding to work on those ones, even though, like you said, it's very difficult. Yeah. On that note, though, because this reminded me, I have now figured out how to merge Gitter, IRC, and Matrix into one room. It takes involving their support, but I have done it. So we now have a Jenkins infra, and I'll talk to Damian later, Matrix channel that has this link to the Gitter channel, which is linked to the IRC channel. It's all three are in the same spot. So now I need to go back and start doing some of the other ones because there was a thread we had months and months ago about merging some of them. And that'll be definitely nice because it's spread out too thin. And if we can at least get the same topics in the same spot, that'll be nice. So I think Alex is trying to get me to do the releases one next. So hopefully when there's all the support for all of the Matrix and Gitter are low, like they're kind of not some heavy commercial products. So they only have like one a couple agents. So I'm hoping this week they'll get back to us and we'll have Jenkins releases into one merge channel soon. And then I just got to keep going through that list. Thank you. The nice thing about Matrix, though, is they have a built-in migration system. So I don't know about Gitter. I think Gitter is transparent. But if you're in a Matrix room inside of Matrix, it'll say this chat has moved to this channel, and you click it and you join the new room. So it's all built-in. You don't have to redirect people. I mean, the redirection is built-in. You don't have to manually say, by the way, we've moved legacy conversations and have my room and stuff. So nice. So we're getting there. More cleanup. Thank you, Gavin. Any anything else on that communication channel transition, then? That sounds very encouraging. No. OK. Any other topics before we conclude for the day? I mean, other than the fact I don't know what Labor Day is and why we're all celebrating it. No. OK. All right. Then I'm going to go ahead and call us done for the day.