 Oh, welcome everyone. This is Jenkins governance meeting. It's the 18th of September, 2023. We've got several topics on the agenda, including upcoming calendar, news, action items, governance topics. On governance topics, I put board and officer elections there to give you a moment just to describe where we're at. Are you okay with that as a topic? Yes, that's okay. Super. Thank you. And then community activity, several items there. Any additional topics that people want to be sure we add to the agenda? Okay, then let's go ahead. So in terms of upcoming calendar, Wednesday will be the next long-term support release 2.414.2. It will also be a security advisory. The security team has announced that 414.2 will include a changes to core to improve security. By way of note, that means there won't be a weekly release tomorrow. The weekly release will be delayed and delivered the same day as 2.414.2. It will be 2.424, 424, and will be a security increment on top of 2.423. Then any questions on the security release that's coming? Okay, next major event is the ongoing Jenkins officer and board elections. Nominations open today and close at the near the end of October. Voter registration also opens today and closes November 5. And voting will happen November 6 through December 1. Any questions on the officer and board elections? Okay, and Uli, we'll let you talk a little bit about the process later in the meeting if that's okay. All right, so we've got announcements of the elections as a blog post, a community post, a tweet, a LinkedIn post, and on the Jenkins Infra GitHub site. So lots of places. Also pleased to announce that Cloudflare is now sponsoring the Jenkins project. And we're looking at possibly using Cloudflare as a way to reduce our cloud costs and improve performance for users of updates.jankens.io. Thanks to Erve Lemur and to Damien Deportel for their work on it. And special thanks to Gavin Mogan for his help getting us a connection to someone at Cloudflare. We've got a FIPS 140 Jenkins enhancement proposal that's been proposed by James Nord. FIPS-140 is a US federal government standard for cryptography use and software. And it's commonly required by by large government and contractors, US government and contractors associated with it. So James has described it there. Java 21 release is coming this week. We are one day away from their scheduled release date. Thanks to Basel and to others for the work there for the to the Infra team. Java 21 Early Access is available on our CI servers. Jenkins Core, the plugin bill of materials, acceptance test harness, and many of the plugins are passing tests on Java 21. And as far as I know, only test changes have been required for Java 21. I'm not aware of any functionality failures. So thanks very, very much. Java 21 is looking quite attractive. No dates. Basel, go ahead. Do we want to do any communication about this? Because I'd be willing to write some kind of external communication such as a blog post. But the one thing that I fear is that we might be overloading people with too much communication. So maybe if we're planning to announce some other Java related changes such as deprecating support for Java 11 in later in October, or something like that, maybe it would be better to combine all of those version related announcements into one blog post or one piece of communication rather than making people read multiple things every couple of weeks that they're saying something very similar. Good question. I'm open to guidance from others on that one because for me it's a larger announcement is there's some power to a larger announcement, but the larger announcement would then be delayed. Whereas they could start potentially sooner. Uli, you have any insights there that you would like to offer in terms of should we talk about it sooner or later? Actually, no. I don't know what she's best. So I think one blog post is simpler for us where we can write everything in one blog post and for readers it's maybe better as well. So consider a summary blog post with the Java 11 end of life, Java 21 support, and Java 17, etc. I think that's what you were saying, Uli, is that would be okay for you. And I think that's what Basel was proposing. Yes, that makes sense. And I'd be happy to work on that blog post, but I don't think we're ready for it just yet because we still have to add the administrative monitor. Right. And in fact, the admin monitor isn't due until October 3rd. So we've got two weeks before we're ready for it. Great. Okay. I like that. Thanks very much. Anything else on Java 21? The next item of news is that the Google Summer of Code projects for 2023 are going well. Two of them have already completed successfully. The work is not final in terms of getting it all the way to end users, but the project itself was concluded successfully and ready for more work to be done. That's GitLab plugin modernization and Docker compose for tutorials. Two additional projects were chosen to be extended and the extensions have been ongoing. One of them will complete within the next week or so, and the other one I believe has two or three more weeks. They're all looking good to pass and looking forward to their results. Presentations were shared last Thursday. Thanks very much to those presenters and to everyone who's active as mentors. Other item of note is the prototype JS is scheduled to be removed from Jenkins Core October 3rd. Details later in the meeting and Java 11 end of life monitors to be enabled October 3rd. Anything on the other news topics? Anything that I missed? Okay. Next is the action items. So Alex and Uli are running the board and officer elections and Uli will give you some time later in the meeting to describe more details there. This next action item, I had actually completed it and the other action items, retrospective, submit the Jenkins IO pull request for sub projects, retire the Chinese, those two I've not completed. So, and it will be several weeks before I make any progress. Sorry, Kevin, anything you want to report on the retiring the Jenkins, the Chinese Jenkins documentation site? No, nothing here. Okay. So we'll do some more work separately on that. And I've still got the open task to draft a license license policy change to the board. It's we've got some licenses that are currently used in the Jenkins project like the JSON license that are not OSI approved, but our documentation says we only use OSI approved licenses. So we need to we need to come to a conclusion on that I'll draft a proposal and send it around. Any questions on the action items? So we're leaning towards just allowing this license rather than trying to do something drastic and eliminate it. My my approach is leaning strongly towards just allow the license and there are several like it, right? Where I think the risk the legal risk and the project risk is very low of accepting that specific license. And so but it's got to be discussed with the board and thankfully the Linux foundation provides access to attorneys that can help with identifying the real threats in the legal sense. So we'll use use Linux. It's a public domain license, right? It is it's a it's a it they changed it from what was it from MIT or Apache with a disclaimer that made it no longer MIT or Apache to pure public domain. Yeah, and there's any precedent from like others other projects that have a distribution mechanism like maybe the Python package index or something like that where where they I wonder if they have a similar I just wonder if there's any precedent in other open source communities or if we're making this decision for the first time. I'll do some research about that. And I would love to love to understand that research. I think that's a very good suggestion is this has to be a problem that others have confronted. And yes, we're a long live project, but others have surely seen it since we started. How do they deal with a mix of licenses? Good question. Anything else on the open action items? Okay, so I'm going to make a note to myself, review, review other projects responses from other projects to license mix mixture like a pie pie. Very good. Thanks. Yeah, I wasn't I wasn't I wasn't saying that anyone needs to go do any work here. I was just curious. I was just thinking out loud and I'm happy to go look into this. And that'd be great. Yeah, I think I'd love to have your help with it. Thanks very much, Basel. Uli, you want to give us a summary of board and officer elections? Yes, I can do it. So my part was very, very small because I was in holidays for a couple of weeks. So everything has been set up by Alexander. So he started a lot of blog posts, the community posts. He created a document where the process is maybe I can post it in the chat the link where the most recent blog post is. So we can put it in the document here as well. So basically, we start now with the registration of the candidates and the voters. So we start in parallel. The registration for the nomination for the candidates is I think it's till October 27. And the voter registration is till November the fifth. So we have a couple of weeks time to nominate candidates and to nominate yourself or register yourself as a voter. And this process is quite simple. You need to go to the community board of Jenkins Community, Jenkins Hi-O. And there you need to enter these two groups. And everything is in the blog post with links. So I think everybody will find the way how to proceed. And the next steps, I'll have a meeting with Alexander tomorrow on how we can split the work. So we will see who is making which thing. So the good thing is we have a good document where the process is documented. So I can have a look and see what steps are to do. I'm not sure if I missed something. So the process is ongoing. Yeah, thank you very much. So the announcements are out and we've already got some people who have joined the voter group. We just need to now be sure we promote it, actively encourage people to register. We've got hundreds of Jenkins developers that are contributing. It would be great to have them also be voters. Anything from others? Okay, then let's go on to the next topic. So Java 11, 17, and 21 in Jenkins, I'd sent a Google doc around to members of the board and to officers with a proposal for how we approach a transition to a new way of supporting Java in the Jenkins project, where we shift ourselves away from supporting three Java versions at a time to just supporting two at a time. And my next stop for this is to send it around to Jenkins developers to the Jenkins user list. And I think I'm going to propose a Jenkins enhancement proposal to formalize it. I wanted to ask the question. I've got a diagram that tries to illustrate that so that people can see visually what's happening in the transition. Are there questions or concerns that we should discuss here that have not been resolved, anything that are issues? I think it would be helpful if you can show the diagram and demonstrate what we're trying to do. Yeah, okay. So the notion with the diagram is that each of the horizontal bars on this picture is a period of life for a Java release. So first bar is first row is Java 11, the second row is Java 17, then Java 21. And what we're trying to do is reach a point where we have a two plus two plus two support model where for the first two years of a new Java release, Jenkins supports it but does not require it as the minimum version. For the second two years, Jenkins requires it as the minimum version and then supports the next version. And for the last two years, we actually dropped support for that oldest Java version so that with a six year lifecycle for a Java release, the first four years we support it either as allowed or as required minimum version. And then for the last two years, we drop it off the list so that we're only supporting two Java versions at a time in most cases. Now, I like Basel's point, he and I were discussing this and he noted this is somewhat of a platonic ideal in that it is a hoped but not a guarantee that there will never be times when we don't support three Java versions. There will be transition periods, there will be cycles like that. That's not a concern as far as I can tell. It's that the general goal is two plus two plus two feels like a healthy pace for the project to keep up with current Java and not burden ourselves too heavily with supporting older Java versions. Uli, did that describe well enough or is there some other attribute you think should be described? No, that's fine. Thanks. Do others have a question or a concern? No, this looks really great. Super. So I will plan to send within the next few days a mail message to the developer list and to the user list discussing this. We know there's a transition period and that transition period will put us into some sort of bumps along the way. Instead of supporting Java 17 as minimum version for two years, we'll only support it for a year. Java 21 will be the required minimum version only for 18 months. Then by Java 25, we're finally on the real two plus two plus two model. One question, Java 21. We are supporting it already in this month now. No, and that's another problem with this six month slices, Uli. Once Java 21 releases, I think we actually will begin delivering Java 21 in our containers, but it's not yet even released. So we cannot support something that the upstream provider doesn't support. Because I think I need some time for my plugins as well to test it locally. So I think of course. Yeah, okay. Yeah. And I think that's a good reason why the Java 21 announcement blog that Basel referenced earlier, it would be good for us to combine that with others, do it in early October. After we've had a chance to be sure that things are aligned with this, and we can even consider including this in that larger picture blog post. That makes sense. So I've seen a bunch of versions of this, but one of them, one version of this chart that I've seen had the administrative monitor with a different color. And that kind of goes along with your point that you just made now about how we won't be ready to ship a new Java version as the default container version for all users right at the beginning of one of these bars. There's basically a period of early adopters and then a period of mainstream adoption and then finally a period of getting the stragglers on board before we finally drop support for it completely. And I guess in this chart that all three of those periods are covered by the yellow portion but within that yellow portion there's a number of different phases of adoption and part of that includes becoming the default in a new container image, which we would want that to happen rather early in order to accelerate the adoption process. But we wouldn't want it to happen on the very first day until the early adopters have had a chance to kick the tires. And similarly, we want to put the administrative monitor in place toward the end of the yellow bar to warn people that they're coming close to the deadline of having to migrate. Would you agree? Good point. I do. Good point. And I had pulled the administrative monitor out because I got some feedback that people were not clear when I put a new color in there. What's the meaning of that color mark? So you're right. And in fact, you can see the sneaky thing here is here's the color that I had. I hid it because it was causing confusion for some of the readers but you're right. There is more subtlety than is covered and maybe it's that one of these bars needs to be expanded in a separate visual which is and this is how it will look for this transition because you're right. It's not immediately clear that there's a whole range of actions in this first two-year period and even before it that are happening. Yeah. Yeah. It might be, you could express that by zooming in to the yellow portion in a different visual and then saying like, yeah, before the beginning of that, there's the preparatory work like what we've been doing in the last month and then once upstream has released the new Java version then there's a whole range of activities ranging from an announcement that it's supported all the way to making it the default in the container image and the default in the new setup instructions all the way to eventually removing it through an administrative monitor and then ultimately compilation error once we require the next version afterwards. But yeah, that's a very wide range of activities within that yellow bar and I think we want to roughly distribute them proportionally. I mean, there's no hard and fast rules but we usually in the past we've given early adopters some amount of time. I think with Java 17 we've maybe given them too much time just because we haven't been paying attention but yeah, I mean at the very beginning we don't want to be too aggressive about forcing something onto all users before the early adopters have had a chance to kick the tires. We have gone a lot better with automated testing so we should be more and more confident. When I started working on this there was more or less no automated testing for new Java versions and now we could say with a lot more confidence that we're running ATH and PCT and all these things. But yeah, I still think we should have some amount of time for the early adopters. We don't want to lose the confidence of our users by forcing something that was literally just released on Tuesday this week as the default in every container image. Right, right. And I like that. I like your suggestion too for the visual concept that zoom in to the first two years and talk about what that means as slices of things that happen there. I like that a lot. Thank you. Good suggestion. And the comment might be that that's a lot of work and it is but the more we formally describe that and institutionalize it as a process the better we'll get at it and the more automation that we'll develop so that eventually this can happen like clockwork. Right, good. Any other comments on on this transition period towards this two plus two plus two model? All right, so let's continue then. Next topic was, oh, I guess there are some key dates upcoming that really just be aware that Java 11 end of life for the Java projects themselves is October of 2024. So Jenkins will not support it beyond its end of life in from OpenJDK so and from Temerun. So it's really we see it coming. Next is that the Artifactory Bandwidth Reduction Project has made very good progress and is implemented. We've still got some remaining tasks that we're working. We've announced the change in a blog post and really pleased with it, but we've got one or two more things still that have to be resolved. They're not as far as we can tell affecting plugin developers and they're certainly not affecting users, but we'll keep working those. Any questions there? Okay, next piece is Prototype.js. And this one, so it all started with a blog post back in May from Basel, right? Thanks to Basel and to Tim Jacome for their work on it. We're now September approaching the October 3 date when this 10 plus year old JavaScript will be removed from Jenkins. Thanks very much to everybody who's made so much progress on it. We've got some lurking plugins that still would benefit by having the change made. Part of JFrog has committed that they'll work on theirs in September, Fortify from Microfoscus likewise, and I actually had contact with Tricentus at DevOps World. So three of the five, there's been at least some contact and some hope. Any questions on the removal of Prototype.js? Yeah, why is this specific date? Is this a special date or is this a release? That's a weekly release. That is one of the last weeklies before we choose an LTS baseline. So it's intentionally selected. It's malicious is probably the wrong way to say it. It is intentionally selected to allow us to get it into the November 15 long term support release. That's good. So that was the intent in choosing October 3. Any other questions on Prototype? Yeah, I haven't heard anyone saying that they need more time or want more time, so this still feels like a good date to me. Yeah, to me as well. I'm a little worried that we're mid-September and I haven't seen proof of progress from Artifactory or from Microfocus, but they've been well warned and we've offered them lots of opportunities. All right, next topic and last one was Hacktoberfest preparation. So beginning October 1, DigitalOcean and others sponsor a month-long event called Hacktoberfest. Jenkins has participated in it for years. John Mark Messon has sent a message to the developer list and we've got a series of issues identified that new contributors can help. We're hopeful for this. It will be a different event this year than last year because DigitalOcean made I think a very wise choice. They've decided to stop delivering physical promotional materials, physical swag, so there will be no t-shirt this year. With no t-shirt we hope that the people who contribute are more likely to contribute because they want to contribute and do something useful. We'll watch it and see. Any questions on any of the topics? One question to the Hacktoberfest preparation, do we still need more issues or do we have enough? Certainly, I think we would benefit by more issues or even more importantly, maybe Uli to you specifically. We've got a list of good first issues that are in the JIRA system but most of them were identified 12 months or more ago and therefore some of them have aged and they're no longer a useful issue and we need to either close them or get them out of the list. I did a sweep through many of the others but I didn't touch warnings, NG, or analysis, figured you could do that. Getting those lists so that a new contributor, when they pick up an issue, we believe it's got a reasonable chance that they can fix it. Some of the ones that I removed were, I looked at it and realized there's no maintainer for this plugin. There is no way if you pick this up you're going to have a good experience submitting a fix for it. I had my plan to go through all my issues and mark them as new be friendly or not depending on the issue. Excellent and that's ideal. That is a great choice. I can show you the current dashboard that I've been using. I find the dashboard quite comfortable if we look at this thing right here. Here's the friendly issues dashboard. I've got to go through core still. I started on core but I've got to do more review on core but I've been through these others that are down the list here and felt like, okay, yeah, there's a potential that these will have someone to review them and we could help. This friendly issues dashboard has been a great help for me. Any other questions on Hacktoberfest? If we're done with Hacktoberfest, I just wanted to share that while this meeting has been going on, I've been googling the Python package index as policy on licenses and it seems like they mostly focus on OSI-approved licenses but also allow non-OSI-approved licenses. They have a separate category for public domain and as well as a few other non-OSI licenses, there's a number of them that they support officially. Even though none of them have a very large number of packages, they include things like the Netscape public license and the Nokia open source license. There's a number of these non-OSI licenses that they allow. They also have categories for freeware and they have a category for public domain like I mentioned and they also even have a category for proprietary, all of which they allow. I think there's definitely precedence for featuring non-OSI licenses in other projects. It's more a matter of how we feel our community values are best served and I don't see any reason why we couldn't be more permissive about. I don't see any reason why we couldn't be more permissive about certain things like public domain or even things like the Netscape public license or other non-OSI licenses. The only thing I think would be remotely controversial is either actual proprietary software or some of these more modern open source licenses that are a little bit more controversial. I don't remember the names of some of them but I know that there are new efforts to write new types of licenses that might be more controversial than some of these traditional things like the Netscape public license but I don't think anyone's asking for us to approve those. It's only the public domain and I think that's perfectly fine. Good. Thank you. Thanks for doing that research. That gives me hope that we've got a path that we can follow that they and other projects have already pioneered. Very good. Any other topics for discussion today? All right. Thanks, every... Oh dear, did I forget to turn on... No, thank you. I didn't.