 Welcome to Jenkins governance board meeting. It's the 23rd of February, 2022 agenda topics. We've got news, press contact email alias, version number change, possibly at a year boundary or possible version number change at when we begin requiring Java 11 highlights from the mailing list and possibly an easy CLA status report. Any other topics that need to be on the agenda? Nothing for me. No. Okay. But that's not starting yet. That's just prepping, right? Yeah, well, and it's in the news section. So, okay. So we had a weekly release, several fixes for icon image things that had changed in 335. We've got the LTS release candidate that's out. It will release in two weeks and would love to have additional testing. And then our, oh, 2020, wow, that's sad. Google Summer of Code 2022 application has been submitted and we are having office hours every week and we had a webinar today. We're delighted to have five previous Google Summer of Code students as mentors this year on the Jenkins project. So one of Google's goals there is to try to retain new contributors. And this is one of those evidences that, hey, the Jenkins project has actually retained several of our former Google Summer of Code students as contributors. So really pleased. We've also got five additional mentors. So a total of 10 mentors right now identified and we're seeking more and more project ideas. Any questions on the news? Hey, Gavin, next topic, press contact email alias. How's the experience going? So I don't know how, what, where and how to talk about. So this has been interesting. I'm going to do an exercise in finding out who cares. I mean, in the most, most true sense of the word. So currently, I think I mentioned last meeting the press page is full of, you know, long time ago contributors. And I wanted to try setting up an email alias and we can fall back on the Google groups but there has been reports more and more of Google groups losing, not losing emails but marking emails as spam. A lot of people are saying that the developer list is now dropping emails on them. So one thing I prototype real quick was or I talked to the Discord support people. They have, there is a support for incoming posting my email and you can actually use custom emails for that. So we can set up a alias. So press at Jenkins.io and that goes to Jenkins, Jenkins.discordmail.com or something. I don't, it doesn't really matter but then that can route to the service and that can be either a category that can be generic thing or that can be a group. The category is nice because you could move a topic to regular some emails the wrong group, let's say press because you move it to the right category. It's nice and easy. But it means you can't add additional people to a thread. So, you know, I set up a group, I tested it out. I couldn't add in her to it. So there's no way to add extra people who might be curious or something like that. I don't know how much stuff we're gonna get to press that would be sensitive and that matters. This, the second option is a group. There's groups in discourse and they essentially it's just an email thread in your little notification box. It's not as easy to work with but you can add or move people. You could split it. You can even take an individual reply and turn that into a topic. It gives us the most flexibility. I think that's probably where I wanna go if we wanna go down this route. Yeah. I did talk briefly with the info team about getting up some aliases for emails which we don't currently do. It's gonna require time. Not probably a lot but time. So nothing's been done on that front. I've been testing with my own address. So, and we've got a recent addition to the info team that is somewhat of an email expert. Stefan Merrill has been added to the info team recently and he spent years doing email professionally. So. I don't think that's the level of requirement that we're gonna need. It's just right now, the MX is pointed at Mailgun which nobody has access to. It's not the right solution. It should be moved to a natural thing you've set up. And so that requires setting up something. I think there's a Linux foundation service that will do incoming email and forwarding and it'll just be done but just have to spend time and look into it. So if this is something we wanna do, this is then we prioritize it type thing. So that's my report on this. I can do screenshots or demo at a later time or whatever but yeah, it seems to work. I think I have Mark, I tried to pick one admin and one non-amend in there to kind of play with permissions and see what would work. So I think Mark and Pokeran will take a look but yeah, it's relatively straightforward. Right, yeah. So it's experiments ongoing and discuss in the info meeting and then again here next time we meet. Sure, I really don't know. I don't know what's in that step. So I think next steps for me would be emailing. This is the hard part, right? Of the who cares thing. I think it's emailing the dev list and saying there's five names on this press page, most of which aren't active people anymore. Does anyone wanna step up or step in or whenever else? The volume of email. So in the year I've been involved has been four, we've had four emails and one of them was about that Confluence hack. Right, so. Excellent, okay. That sounds great to me Gavin. Evelina, any objections from you? Does that seem okay to you? No objections. Okay, great. Let's go forward then. Excellent, thanks Gavin. Oh, good. And then I think I brought the next topic which light leads into yours as well. I've been keeping an eye on, so I have a thread on the forums about doing announcements more regularly, more public. So, you know, new, new, since things are doing with the highlights mail and that's that kind of thing. One of the things I've noticed is that over and over again, people think the Jenkins are doing Sember, right? They think plugins are Sember. They're like, oh, you only changed the minor version but this major thing changed and they think that's, you know, they're looking at the version this way. I was thinking, you know, we can move to more of a dated version number. So, in this case, so Ubuntu does, you know, I think twice a year, they release a dated one. So, 2304 and 2310 would be the ones this year. Is it that? No, 22, wow, I started that phone. 2204 and 2210. But then, you know, that would, we could do one, we could do per week. So 22.1, 22.2 and F52 releases. It just makes it a little bit less. People assume that it's a minor release set. You know, they're not seeing, you know, version 2.303 thinking it's slightly different than 302 type thing. Right, yeah, exactly. So there are certainly plenty of examples in industry doing it that way where they're saying, they're admitting, look, let's get on a yearly cadence. And one of my worries with the current version numbers is how often lately I've been juxtaposing the digits 2 and 3 in various interesting ways and making mistakes in bug reports and other places where I just simply say things wrong. Yeah, and, you know, when someone in Gitter says, you know, I'm upgrading from 2.100 to 2.303, you're like, okay, so that's divided by 52, that's, well, that's a two-year release. Yeah, you know, and this would be a little bit more quick and easy for us to go, oh yeah, you're upgrading from one those four years ago, you really want to do it this way or you really want to follow these release notes. The problem is though, you know, we do have infra failures once in a while, you know, like a bad tagging or CI pipeline easy fix, and we usually just skip the release and go like so instead of, you know, maybe three or one failed, but three or two is fine. It'd be a lot more obvious for that. Yeah, but okay, it's going to be, it's fairly obvious anyway. So I think it's an interesting one and I like the notion of if it's, now would you envision LTS would be 23.01.1? Yeah, that would be my thinking. Yeah, so I don't have a strong opinion here but I wanted to bring it up and I thought it was worth discussing. Yeah, I think and leading zero intentional because we would expect to not have more than 99 releases in a year. I would hope we would not have more than 52 releases in a year, but yes. Right, okay. Because yeah, 99 would be, no, 99 would be just less than every release failing once. Right, okay. So what was it? 104 would be every release failing once. Yeah, so I think yeah, that would be legit. Good. So I think it's worth a conversation. This is probably one that justifies a context of a Jenkins enhancement proposal. And, but I like the idea. Let's hash through this one as compared to the next one. So this has the benefit that we just do it on a calendar event, right? It's annual. We're not trying to declare some features are bigger or smaller. We don't waste time or energy having those disputes. It's just the calendar that occurred. It's now the year 23. We're going to make the version number 23. Yeah. And it's like, I've been in a situation when I had a couple of Jenkins instances to review that had different versions and every time I just had to check when was this released? Is it something that is outrageous that is still up and running or not? And if you see it very clearly that it's a year or year old version or something, then it kind of screams update me or something like that. So I think it's worth exploring, definitely. When you log into Ubuntu Box and it says 16.04 on the login screen, you're like, oh no, no, no. I'm not touching this machine. Getting out of here right now. Or 14 or 12. Yeah, exactly. All of those are reminders. So, and Evelina, thanks for being the voice for the users. That experience is good justification to say, hey, you know what? This makes it very clear. And truly we don't have strong semantics for the version number two, right? It just doesn't, right? It's long ago. We've been through multiple major changes. We went through tables to divs. We went through, we're now in configuration form, modernization phase one. We'll go through phase two in June. And none of those have rolled the major number. So I think it's worth considering. In the end, those major numbers means something to you, to people who are developing it. Yeah, to the user of me, one thing, to the developer of me and a different thing, to the writer, the news reporter of me and the third thing, it doesn't mean anything to anyone. It may mean something like, okay, that might be a tricky update, but upgrade or something. Which is what the LTS is supposed to kind of handle. Yeah, good point. Now, I don't know what the impact is in various places of making such a change, but I think it's worth us evaluating it, bringing it as a proposal for discussion. Yeah, I don't touch core. I don't know what the implementation details would be. I don't know. The lease officer would have to be involved. Right. You know, I think about it last night. I think, again, we have so many people going, I'm gonna update from this version to this version, and I go to the change log. I'm like, okay, you know, 100 was, yeah. Right, you're applying all sorts of internal knowledge because the version number gives you no hints about it. Whereas if we switched to at least annually, the hint is, oh, this was in the year 23. Yeah, good. And we can be like six months ago, tables to div happen. So that's probably gonna be 2106. Okay, if you're in that range, maybe this is the problem. I don't have to go look at the change log. And I know Mark knows every version by, you know, is memorized in perfect memory on that, but the rest of us have to look that up. Yeah, exactly, yeah. Okay, Evelina, you look a little perplexed. Are you okay with this as it stands? Yes, I'm okay. Great, all right. Anything else, Gavin? So I assume the next step there is a, do you want to work with me on a JEP for it to try to describe it? Do you want to do it yourself? I don't want to do it myself. I'm not really sure I want to do it at all, but yes, I think that is the next step. So I'll probably get help from you in writing it. Okay, great. And I've got to explore some, certainly my employer will want to think carefully about what does this mean. So CloudBees is, and I suspect Red Hat may care. There are several other companies that are shipping things based on Jenkins, so we'll want to put it into the community and use the JEP process to vet it. Yeah, yeah, yeah. And maybe we just go to three. I mean, so there's all kinds of other, there's actual technical requirements. Chrome and Firefox are apparently this week, this month, both hitting version 100. And they're actually finding, well, in the case of browsers, there's user string parsers that are just breaking on a three-digit code, right? Right, because they expect two digits exactly. Yeah, so I mean, there's going to be more than just, hey, this is a cool idea. We're going to have to actually spend some time and see, you know, do we have version parsers, especially in like the plug-in site or, you know. We've got version number lib that definitely has some special knowledge about version numbers. So yeah, absolutely. Evaluate feasibility, et cetera. Good, I like that. Thank you. Okay, so and given that conversation, I think I'm mostly prone to drop this topic. I had considered, should we roll the version number to three.x when we require Java 11 or newer, because it's a major change. It's conceptually a breaking change because it may be that code, once we require Java 11 will not even execute on a Java 8 virtual machine. And so that for me was possible justification to roll the core version number from two to three. However, we would have 22 major versions before we have an issue, right? We can still do both. And I do think like if we start this year, we can do 20, what is it? 20 major versions before we even have a real issue, right? Overlapping the two processes. I do agree that a 3.0 actually sounds valid for Java 11 requirement because it signifies that you have to go look at the upgrade notes or the release notes, you know? Okay, good. And Evelina, thinking from how the users experience it, are we going to cause frustration and irritation if we, let's say in September, we roll to version three and then in January, we roll to version 23. Are we going to cause irritation, frustration, aggravation, should we have skipped September's role I mean, I imagine, I know in the customers I was working with, we, for example, for automatic upgrade of the plugins in using Jenkins's code, Docker, we were parsing Docker file to get the latest version, the version of Jenkins they are using. So I imagine there might be situations where there is some regex that users use to check what's the current version of Jenkins we're using. And if we can keep it to, I don't know, a number dot, a number dot, a number, then it's not going to be a gigantic change, but... I think Mark's comment was, and I don't, I think people are going to get upset no matter what, but I think the question was... I don't want to be that pessimistic, but it's not like it didn't cross my mind. No, no, but his comment was, if we roll to 3.0 in September and then in January, we go to 23.1, are people going to be upset? And the answer is probably some of them, some vocal ones will be, but most people are like, cool, new version, keep going. Yeah, and I mean, someone always will be upset. I do believe, as I mentioned before, that it does make sense. I would welcome it as a Jenkins user to have the version that tells me that it's fairly recent version or straight away with the number. And there might be some adaptation needed. And I'm not saying we have to retain this format, but probably sticking to that format would make it a little bit easier for some to transition. For many, it will be, I mean, they will barely notice really, so we'll not make everyone happy, but as long as the change makes sense and is supposed to bring a value, then, yeah, we should try. I'm thinking of the version number for plugins, for the, what is it? I don't have a better name for it, the CD version, the JEP to something, where people saw these new version numbers and panicked. And so we got to just be careful about making sure we communicate that because no one really has, and it's scaring people. And I don't really have a good solution to fix that. Yes. I mean, doing whole numbers, so 23.01 and 23.01.1 will be fine, but it's just something we want to make sure we make clear in communication. Makes sense. Yeah, but it doesn't mean that your Jenkins is 20 versions behind or something. Yeah. Right, we admit we're doing a discontinuity and it's an intentional discontinuity for the benefits we get on the other side. On their hand, Debian never changes the version number and you're really confused because it just changes the wording. Yeah, I really love Ubuntu's alphabetical naming because I know that A precedes B and D precedes B. Oh, I didn't even know they're alphabetical. Oh yeah, they are, absolutely. The animals they choose are alphabetically named rolling and it's really great, but yeah. Yeah, and then they roll over. They roll over to A again. So they wrapped around. Well, I mean, like Debian's, I think we're on 14 now it's stable, but maybe it's 15, I don't know, you know? No, it's 11 is stable, it's bullseye, but yeah. Wait, it's 14. Is 14 like the most unstable one? Yeah, yeah, on and on. Yeah, so yeah, I prefer dates and I've brought this up before and it kind of got the same with the 3.0 release, it kind of got meh, who knows? Well, and see, I'm gonna, JEP 2, I think it's 236 has been merged. That's the required Java 11 thing, but I'm gonna bring this, I think, as a pull request to that as a revision because I think it's worth the discussion in the larger community. Requiring Java 11 is big enough. Let's consider rolling to 3.x and at least have the conversation. Yeah. Okay, great. Anything else on that version number topic? No. Okay, next topic then. Highlights from the amazing list and community forum. I know it's kind of silly, but there was a thread with someone commenting about your ability. I think it was the platform meeting minutes where you had everything in chapters and different timestamps and I just want to double up, I wouldn't say chairing, but managing what six meetings for Jenkins and posting minute notes and having recordings and they are very well done and very organized. Well, and happy to do that. I only do those chapter things for meetings where I think chapters are really, really important. And the UX SIG is one of the words, it's white hot, right? People want to see exactly the thing that is being highlighted and so they jump right to it, see the little demo and then they're done. Yeah, good. But the whole thread, just wanted to shout it out here as well. It's a, yeah. Thank you for doing that. Happy to, thanks. And then I'm throwing out Daniel Beck released new GitHub Actions for doing basic security scans on plugins. So any plugin author can opt in and get warnings saying, oh, you're using this key says it's a secret, but it's a string. So you probably want to use a secret variable or you're not requiring a post on this endpoint. So all the basic security scanning that they do can now be done on a PR. So you don't introduce new stuff. It's pretty getting pretty good results so far. There's been tweaks on the actual permission model but so far everything looks pretty good. Yeah, I was delighted to see positive comments from Jesse Glick and from Basil Crow, both. That's two very, very positive endorsements for me. And yes, I'm sure it'll get better. And then the last one I'm adding because I'm biased and so is Mark. But the Markdown for a matter of plug-in, I forgot we never never posted that I released it. So I put it in the forms saying that you can replace the HTML parser, the safe one with a Markdown parser and it will let you put Markdown in anywhere you had to put HTML before. And PS, thank you very much. The terrible thing is I've got probably 100 or more jobs that I have to go undamaged all the HTML I inserted into them so that I can use Markdown to make them easier to read. Thanks very much, Gada. All right, so I'm gonna drop the easy CLA report off the agenda, Oleg's not available. Any other topics we need to discuss today before we close? Nothing from me. All right, thanks, everybody. Recording will be available probably within the next 24 to 48 hours. Sorry, Mark, did you have a recording for last week? It's not on the minutes. So I don't know if it got posted. I think for the one, two weeks ago it did get posted. I just haven't put it into the minutes. Yeah, I didn't. One of those failures on recording activity. No, it's all good. See ya. All right, thanks.