 Welcome. This is Jenkins governance meeting. It's May 4th, 2022. Thanks for being here. Remember that we abide by the Jenkins code of conduct. So topics for the agenda today, news, action items, Linux Foundation survey, and then forums and topics. And those are the only ones that I had. Are there other top and anything Gavin that you want to bring we had plug in site last time is there anything else you'd like to highlight there. I don't think there's anything that comes to mind, but usually on the spot something comes up right. Okay, well so, so if we if we need it it's there. All right, any other items that need to be added to the agenda. Let's go ahead. So the Jenkins 2.332.3 LTS is in progress. The build has been built has been run. And is tag. Packaging has the release checklist is in progress. So Alex is running the release checklist and he'll, I'm sure report when release checklist is complete. For instance we probably still need Docker images some other things in progress, but that I see no reason why that won't be a successful release it looks good. Thanks to everyone who contributed. So then anything else on on news items. Next topic then I've got to open action items. I've still not not progressed on these, and I won't make progress on them for probably weeks or months, just given my other workload. My apologies will just carry them forward. The second topic was Linux Foundation had asked to be given our mailing list, so that they could certainly not not Linux Foundation I'm wrong. That's right I need to correct this it's a CDF, the continuous delivery foundation our parent organization asked for the list of developer mailing addresses so that they could send a survey to active maintainers. So how sensitive we are about that list of of who the developers are and what they're not so much who but what their mailing address is we countered with an offer we'll send to the developer mailing list, the registration URL and let them know that's been done. And so that's been done. Now I haven't heard any report back yet so how about we give me an action item to ask for a status report on the number of of registered survey participants. Because one of the worries is if they don't get enough participants, they may not get may not understand what what benefit we're receiving or what our maintainers need. It's kind of a lack of what we get out of it as an individual user like why should I give them my email address. I think it was kind of too late to do it after the fact but I realized reading the email there's like, hey sign up and do the survey you're like, I'm good. That's a good point so they don't know how they will benefit how they or the project will benefit from the survey. Right and that's, that's a good, good point so if it's just a survey for the joy of surveys, that's much less motivating than. Yeah, if we learn from this survey that we need to provide these services we might provide those services. Good point. Thank you. And, you know, again for the future we should probably make that clear before they click on the link. The motivation for the survey in the in the survey invitation email. Yeah, good point. And it points to a problem. I wasn't sure what the benefits would be I know they'd asked to do the survey but it wasn't clear to me what gain might we receive from it. Good. Thanks Gavin. All right, any, anything else on the CV is CDF request to survey maintainers. Okay, next topic. Next topic then forums and topics. Gavin, you want to leave us through any particulars. The only one I added was the one at the end, someone posted to the forums this week that they developed a. I think a desktop application as a drinking dashboard. And I'm always encouraged to, you know, bring them up when they come up as cool projects. So I have not unfortunately had a chance to try it so I don't have anything else to say about it but it looks like a stand a little tool that shows a pretty high level overview of your drinking server or your drinking jobs. Thank you. Yeah, thanks very much. And it's cool to see those kind of those kind of small projects. Sorry, what was that Gavin. I must have one time sorry. We can hear you just fine. Yeah, sorry, I got muted. Okay, got it. So one of the one of the hot topics here is the next LTS baseline is now we're now at the point of about three week we are just three weeks since the date had been planned to be selected. I'd asked for a two to four week stabilization period. We're now at 2.346 and it was released on Tuesday, and fixes a few more issues. There are still one or two still a few remaining that for me make 2.347 the most attractive, which will be next Tuesday. Now it's Tim's Tim Jacome's call on when when we actually choose the baseline as release officer but for me I see a few still that are getting work and that look very promising that we will probably have them merged in time for the next weekly. Any comments from others or concerns there in terms of LTS baseline selection for June. Okay. The next piece of news for me was that the, the Java on which were based has been rolled recently it's been released a new version. In particular it was important that we get Java 1703 out because there was a security issue reported there. We didn't think Jenkins would be affected by it but it's much easier to update to a new version of Java than to people why we're not affected and have them be persuaded. The 17s are like experimental images right. Exactly. 1703 is Java 17 is, is in preview for us. And so we're, but even with it in preview it's nice to have rolled to a new version so the images for Jenkins 2.332.3 will use Java 11 015 and Java 1703. They will not use 8U 332 because it's not yet available from from Eclipse Temeron from the adoptive people there. They've got the 17 and the 11 which they correctly prioritized higher. The issues were more dramatic in 17 than they were in the other two versions. Any questions there on on that topic. No, it sounds good to me. All right. And then we've got the Jenkins enhancement proposal to require Java 11. And it does look promising that we're going to reach, we're going to make it to September. We need more details in the communication plan. We need specific dates for when we're going to make certain changes or specific weeks prior to the release. And I've still got to do those things so that's still pending, but it feels like September LTS is a good fit based on. Thanks very much to the work of Basel Crow and others who've made made great strides in assuring that the tooling is ready and that we can do Java Java 11 native builds in that time. So to clarify I think the goal is for requiring Java 11 in the September LTS but will require Java 11 earlier than September in the weeklies right. Right, exactly. Is there a go no go date for this. I think that's part of the part of the layout the plan so I've got to do some more detailing in the Jenkins enhancement proposal. We would typically would typically do it would be commonly done for us change this significant immediately after the LTS baseline is selected for the preceding LTS. So the one workout right now, exactly, which would mean we would be doing it in a common pattern within the next few weeks. I'm not sure we're ready to do it quite that quickly, but it's it's in that time frame right because we want multiple we would like to have a good long period where the weekly is already telling people, hey, this is on requires Java 11 and use that to be sure we're confident that it will be good for the LTS. I mean the plugins will be requiring to have 11 yet it's just that they could use it. I'm just thinking of some plugin authors like to go really fast and quick. And we had issue with tables to give a few other ones where people were updating their plugins before the LTS was out and confusing the hell out of people. And I'm just concerned about that. And that that updates their minimum core baseline to a release that requires Java 11 will themselves require Java 11. But the plugin maintainer has the choice as to when to update their core baseline and most plugin maintainers don't choose a weekly release as their baseline in order to give themselves access to the widest. I mean, you say that but also when tables to div came out everyone did that because they had to and it was a very confusing and operate process because a base center isn't the greatest at saying why plugin is available just says it isn't available for your version people are like, but I'm on the latest version and you're like yep. I'm hoping that we won't work that we won't require any plugin maintainers to update their baseline tool weekly. I think that has been the case for some user interface changes including tables to divs. Yeah, well some of the icon changes that have been done recently, but that should not be the case for the Java 11 transition. Yeah, so I just want to make sure I bring it up because it was bad for lack of any more descriptive term. Good, good point. So, so the the idea there is, we would roll to require Java 11 and weeklies, but we don't mandate and there's no compelling reason for us to mandate that plugin maintainers must update to use one of those weekly versions as their minimum version version because there's not, there's not any, any compelling reason that I know of force that unless they need to do it for something else like for some UI change, which potentially could cause a problem so we got to be careful about doing an important upgrade at the same time as how to phrase it but we're like we don't want to have a UI update that everyone should upgrade to at the same time we're doing a new LTS Java 11, because then the issue will be accidentally forced. Right. Right. And that was one of Mark's motivations for doing the Java 11 requirement in a different LTS from the recent UI work, just to put some breathing room in between these major changes to the ecosystem. That's an excellent point. So yes and using September instead of June is is we hope quieter LTS with regards to UI changes right so we've got really important UI changes in June has some really June UI changes are significant and and really am quite impressive. But they they need more care and more work so we didn't do didn't want to do the the require Java 11 in that same lockstep. Yeah, good point. I feel like that means in a couple months it can be very exhausting for everyone going my stuff doesn't work you're like yep update your stuff. Well, and, and that's part of the story right is that we've got messages we've had messages for now, nine months or more that say Java 11 Java 11 is is recommended. And most recently we've had even stronger worded messages that say Java Java 11 is going or Java eight is going away. I know it's more of a docs, probably thing but can someone also write up a canned response for the forms. Oh, good idea. So that if you know it's one of these ones that says oh you need to upgrade. You know, this is what you should say and then we don't have to, because I know Mark and I have different approaches where I just like yep it's fixed and Mark's like, here's links to 13 items and I'm like yeah I should do that but that's a lot of work. Well, and I think it's a good, good idea to look at the responses to tables to divs. Just to get some background on what are the kinds of responses that will help people and what are the kinds of responses that they were wordy and they just ignored. Yeah, right. Well because I know the one there's the one that said about boost, the bootstrap and the class loader and so with that and I think that's a guava update. You know, if we see that error, we can just usually say hey, you know, we read this form post but remember to look at this form post so I was just thinking you know something like that where we just know that that's an error. You deal with it this way, you know, for more information see this blog post like we don't have to do very detailed but just like, right. Yeah, I like that idea and the, maybe that could be as simple as linking to the upgrade guide, which ideally would have all of that information. One of the most important pieces that I think we need to communicate is, if a user is having a problem what information do they need to include when they file the bug report. And we've included that in the upgrade guide for the guava upgrade and several other changes that we've made. So I think the expectation would be that we also include that information here. So most of this was the other example, you know, we read that in the upgrade guide, you know, when you file the ticket include X, Y and Z. So having that as a canned response ahead of time would be great. I would love to see, like, automated triage bot for both the forms and a GitHub where you know, I see that you mentioned bootstrap and class loader. If it's not someone will look at it soon, you know, because it's exhausting sometimes to do those initial triage. Right. That's a longer term project. But, you know, the more we think about it the more we think about it in the future and have can responses ready to go the more this is doable. Right. You mentioned you mentioned bootstrap and guava or bootstrap and class loader. Right. So I think it's food. See this for more information. Yeah. Good. Yeah. Excellent. Thank you. Any other observations or comments around the required Java 11 effort. No, I'm good. Okay. Great. Thank you. Oh, oh, I take it back. There are more. There are more things to announce here. I should note this one. We're going to have a contributor summit at CD con in June 9th. In person right face to face mano a mano June 9, it will be so it's you, you can register independent of CD con so you don't actually have to attend CD con in order to attend the contributor summit. It's not yet possible to website. I don't know if it can be done by phone or another way but for the time being it's not possible on the website yet. Okay, so not yet able to do so. Good. All right. So who's going to be there Mark wait, Tim Jacome, Alyssa tongue. I'll plan to be there. Others we we invite others to attend would love to oh and Bruno I think we're trying to get you there right. Where should be. Yeah. Others we certainly welcome you would love to have you there and and also understand if you can't be there. Yeah, unfortunately I'm not barely leaving the house let alone the country. I understand the whole crossing international boundaries and getting on an airplane has has some level of terror at this point doesn't it it's a little bit scary. All right, any other topics we need to discuss. That was a pretty good productive meeting. All right, thanks everybody recording should be available within the next 24 hours. Thanks very much for your time. Have a great day.