 Welcome everyone this is Jenkins governance board meeting it's the 10th of July 2023. Thanks for being here topics I've got on the agenda for today include news and action items and community activity. I don't have any other topics other than those three are there any topics that need to be added to the agenda. Other than those three. Okay, then let's go ahead. So first topic was the news item. Thanks to Christian and Alex Brandes and others jankers 2.401.2 released on time during the 28th. The next LTS baseline will be selected two days from now Wednesday 2.414 looks promising 2.413 looks good. So looking forward to that and thanks in advance to Chris Stern for his work on 2.401.3 that will be coming up at the end of this month. Thanks to the Linux Foundation for the infrastructure upgrade. Alex Brandes detected that we needed to go from Jerry to Jerry nine they completed that last week. Thanks very much to them. And I'm now a member of the CDF technical oversight committee voted in any questions on the news items. Okay, then let's go on to action items. On the action items, I am pleased to say that after only maybe two years. Okay, maybe a little less but after an extended period the governance meeting archives has been created and has content in it. And it's got the material from 2023. So, here it is as a markdown file and visible ready to go. So we'll continue using that there are certainly improvements coming in the future, but it's there. I've also started the retrospective on the signing certificate renewal process and this is a long list of historical items and mistakes at a number of points. There's still plenty to do here to think through this to work through it and to be ready to present it but others are welcome to comment on this document to, to offer their insights, etc. There are plenty of things that went wrong in the signing signing certificate updates and lots of ways we can improve to open to action items that had no progress the conversion from sub projects and six to working groups. As we get a lot of work hiding there and retiring the Jenkins Chinese documentation site. The first step has been done in that the Chinese link is gone from the top level page, but the Chinese pages are still responding and I think that still gives us the risk that Chinese users will follow installation instructions in Chinese that are simply wrong. So, so we want to finish that it's going to be a while. We still find them from search engines for example right right and not just search engines from bookmarks from all sorts of places where, where Chinese content is is still there. And some of the pages are valid if they're unchanged from when the translation was done but the install guide for instance is completely different. There's no no update for system D in the Chinese install pages so they're completely complexed when they read the instructions there. Any other questions or concerns on the action items. I just wanted to mention a related topic. It's part of the work on as part of the work on upgrading HTML unit and generally modernizing plugins that deprecated the translation assistance plugin. Because it was several years since it was last updated and released and also because the server that it was transmitting translations to has been shut down for a very long time. So, you know, I'm not really sure what the status of our translation infrastructure is because I know that there were some efforts to some efforts to use that that new service. I don't know if that's something that we're still using or if it is something that we are using if it's documented anywhere or if it kind of works out of the box because this translation assistance plugin was very well integrated with Jenkins I mean you could just go to the bottom of any page and click a button and start translating things. It's quite that simple with crowd and if you, if you have more steps that you need to go through. And if those are documented somewhere but. But yeah I think in general I think we have decent infrastructure for translation. And in when we moved to Java 11 we, we migrated to UTF a for all of the properties files in Jenkins core and I think that's helped a lot of people, because they don't have to deal with the coding problems that we've had in the past so we've made some progress there. But yeah, in general, in general I think there might be some more polish that we could add to the whole translation infrastructure. Although I think I think crowd and it's working pretty well overall. So, that's really all I had to say. Excellent. I think Alex Alexander if you want to comment to, I know crowd in has been documented and it's used by several plugins, but it's certainly not used by Jenkins core. And, and there's, there's still plenty to do there any insights you want to share Alexander. To comment on the translation, I think translation assistance plugin is the proper name, the server for that shutdown like in 2020 or something like that. But you could or still can use the plugin locally to submit translation proposals to the local instance Jenkins runs on, but you can no longer contribute contribute the spec to the plugin. In case this is a valid use case for some people. But I just said they are like 12 or 13 plugins using your 12 plugins using crowded at the moment integrated with and get top if I see that correctly. So I think that builds a solid base but yeah you're right Jenkins core isn't integrated with it yet. Well, and I admit I'm quite impressed with cloud in because what it, it is not as tightly integrated with the Jenkins experience as, as the translation assistance plugin was but it provides translation memory and translation suggestions that, at least for me as a as a as a poor speaker of Italian, it does a much better job for me than the translation assistance plugin did. Now I'm probably the wrong person to Italian language translations you can hear from my, my accent that I do not have an Italian accent. Yeah that works basically out. It remembers what you have submitted to other plugins and other projects within crowded and offer suggestions matching the context something is in. I have to admit I don't really know how the translation assistance plugin used to work under the hood so my knowledge is pretty limited there. Good, thank you. Thanks very much so yes that is so good it's a good place that we could do significant improvement in in making things more plugins use crowd in and eventually getting to the point where core might consider using crowd in. Anything else on the on the Chinese Jenkins site or crowd in related topic. All right, thanks puzzle. Next topic then was community activity. And here this is just my poor, my poor summary of how things have been happening in the community in the last two weeks. So that we had for Google Summer of Code projects that's presented their midterm evaluations last Thursday. Recording is available along with the slides. Thanks to all four thanks to those who mentored and arm entering the projects will continue midterm evaluations are due to Google by this Friday. And the Jenkins project or Gadmonds have asked that we submit them to them by Wednesday I believe it is. So, making good progress. The Artifactory bandwidth reduction project needs more progress. Right now J frog has asked us please. It's time to lock the. It's time to prepare for the future state where the cash repositories like repo one like the eclipse J get repository are private instead of public. So we've got to do a series of evaluation changes, modifying parent palms with prototypes to switch from reading from repo Jenkins CI or to instead read from each of the provider repositories the J get repository repo one, etc. Repo allows to continue to use have the cash copies, but they need to be private so that if we need to use them ourselves, we have to authenticate to repo in order to use them. Any questions on the bandwidth reduction project that's one that has me worried but we've we're making will be making progress over the course the next month or two. Okay, next topic then is prototype JS. So thanks to Basel and to Tim Jacome, the 2010 prototype JS JavaScript library is being removed. It's been all references to it have been removed from Jenkins core and a feature flag has been implemented that allows a Jenkins core user to actually turn off prototype completely. Well, right now that doesn't help much because there are some key plugins that have not yet integrated and released their removal of prototype JS. And you can see the status of those in this tracking sheet. Thanks very much to Basel and to others who are maintaining this Basel I think it may just be you whoever it is, thank you, thank you, it's a beautiful piece credentials and declarative pipeline are the two really big ones. And then we get down into the still big ones, but not as big get parameter for instance Basel, I think you've submitted an adoption request for that one. So that one's coming others further down need more and more, more work. Any questions on prototype JS removal. Yeah, this is this is looking a lot better this week than in previous weeks. If you go back to that list, I can, I can give some updates pipeline model definition. I need to change that to yellow because it was merged over the weekend. But it's hasn't been released yet. Similar to blue ocean. And get parameter. I have an adoption request that should hopefully be clearing by tomorrow I think, which will allow me to release that fix. So that's our choice. We've got a contribution from the community, which I've already proved, and which is simply awaiting a little bit more testing by the maintainer before it's merged and released but I think we're looking very good with that one. Thanks to to Rahul for contributing that fix. It was a, it was a fairly difficult change to implement. And I was really happy to see how this one turned out. Because we also added, or I should say Rahul also added a lot of automated front end testing prior to developing this fix. We're in a lot better shape, maintaining this plugin now, and in a much more confident state to implement future refactoring and and other changes. So, yeah, no choice is looking pretty good. I've also got an adoption request for categorized view, which might take another week or two to clear, but that one. That one should also be in good shape once I get released permissions. Most of the items below categorized view. I still don't have pull requests open. The Docker Hub notification plugin is maintained by some cloud beast internal team, and I have also pinged that team to that one I think should be okay. The ones that I'm worried about are mostly corporate maintained plugins like fortify is maintained by a corporate team. Not, not a cloud bees one but some other company and similarly synopsis co verity is another corporate maintained plugin. Same with Q test. Same with open stack, open stack cloud. Same with Azure app service. Same with Oracle cloud infrastructure compute. So, I'm not really sure how we should approach these in the long term because it's almost impossible for a community member to go and test these changes, they're typically integrations with some sort of third party software you know whether fortify or Q test. And without access to these proprietary packages. It's almost impossible to do testing of these changes. So these really need to be done by someone who uses the plugin or by the corporate teams that have developed these integrations. So that's why I haven't submitted any pull requests to them. At the same time, I have gotten very little in the way of responses to the various issues that I filed where I've, where I've asked some of these corporate teams to take a look at the use of prototype. And I think that's because we haven't set a clear date by which we want to do this by so there hasn't been a huge incentive to start tackling this issue. Well, that's that's one of my theories anyway. But yeah, I'm not sure what we could do to more strongly encourage these corporate teams to tackle the prototype removal, but I don't think it's something that a community member could implement without actually being a user of this software, unfortunately. So I don't know if others had any thoughts about how we could more clearly communicate that to these long tail corporate plugins. So the crucial challenge there is this is not the prototype changes not the kind of change where you make the change and don't interactively test it. It's critical that we interactively test every one of these changes and make sure that that code is executed correctly. Yeah. Okay, and so, so therefore you have these these integration things you've really got to have the other side of it right it's it's I see your point thanks. Yeah. Development wise, or as the kind of problem it's similar to tables to diffs know. So, I don't remember exactly how we went about there, but I think we said the dates that at this point tables to this will be merged your plugin will needs to be adapted we will file the issues for you will will take care of the most popular plugins and after that. It was up to the maintainers. I mean, with these many plugins and the problems and actually, you know, not being able to test any potential changes that we might be able to submit. This is the basically the only way to go about doing that. No, I know, I know that it's inevitable to some degree I'm just trying to minimize that amount of you know collateral breakage to the to the degree that it's possible. But I think the biggest action item I can come up with is that it would be good to get some agreement on when we want to do this. I don't have to decide it right this the second but if people could start thinking about what timelines and make sense I think that would go a long way as Daniel just alluded to. Once, once we have a better timeline then that would be a strong motivating factor to address these issues. I think that this could be done for the next LTS release would be something that we could only consider for the LTS following the next one at the earliest, but yes, right because we're choosing the next baseline day after tomorrow. So it's a little late for that. Well but but it is feasible to choose to try to fit this into the next 12 week cycle, so that we could have this have that that boundary date, actually on the next on the LTS after, you know, the one that will be 16 or so weeks from now. Or the one after that I mean I'm not in a hurry to do this but whatever, whatever we decide on. This I mean we should communicate very clearly. So we have a little more flexibility than with tables to divs if I remember correctly there. We decided to basically merge the change immediately after the LTS cut off. The most weekly releases before we cut the next LTS baseline to take care of regressions this change looks extremely safe and well understood and it's in core already. As an optional flag. So I don't think that problem applies there so at any point in the next three months should be fine in my opinion. I mean I also am aware of some proprietary plugins that need to be adapted that are not on this list because they're not open source, but that's, that's why my, my gut feeling is that the next 12 weeks would be fairly aggressive. And it might need to be, you know, the next 24 weeks that we're looking at rather than the next 12 weeks to be to make sure that everyone's really on board. Well, next 12 weeks means it will be in LTS within 18 weeks. Right. Yeah, I think to consider. Yeah. Well, I think this ultimately comes down to who wants to be driving this effort to remove it from core and I haven't been taking that role myself because Tim has the draft pull request to switch off the flag. So, I wanted to make sure that others are involved in the conversation. But yeah it seems seems like the sooner we can agree on when we want to do this, the better. And I don't want to make that decision myself. I think that makes sense. So it feels like it may be a there. I mean there are still there are still items very high on the list that say it would be a really bad thing if we if we merge that into Jenkins core right with credentials and declarative pipeline. I think it weekly would be would be terribly disrupted if we merged too soon there. But having the discussion and the developers list, at least to say okay should we should we look forward and try for a merge within 16 weeks. And then that conversation about okay what would that mean in terms of timeline and which, which LTS version would it go into etc. Good, good point. Okay, if I started that conversation Basel do you you do you have any objections if I start that conversation to try to ask about that just to get people thinking about it I think I think you may be right that 12 weeks may just be too aggressive, given given the number of things that need to be done particularly, not just proprietary plugins from my employer from cloud bees but also proprietary plugins from other other large companies right from synopsis and others. It's, it's in in everybody's best interest that this be a smooth roll out and we'd like it to be much smoother than tables to divs was. Yeah. Yeah, if you're interested in having that starting that conversation that's fine with me. I don't mind starting it either but I was just, I was just waiting until more of these rows it turned green but yeah I think I think it's an important discussion to have. All right, thanks. Anything else on prototype JS removal. I was wondering about the feature flag how has your experience with that been. Are we aware of users who enable it and just try it or, you know, is there a non developer use of this do we know that. Yeah, there's at least one, because we had one bug report in community Jenkins or one reporting community Jenkins that I oh hey I turned off prototype JS, and things fell over badly. And they fell over badly because, because some very high on the list things haven't yet remove their use of prototype JS. So we know there's at least one usage of that feature flag out in the community. I don't know beyond that. And Daniel it's a you're more familiar with it than I am is there usage data reported centrally on feature flag, enable disable I suspect there isn't. I haven't seen anything, but it could be added pretty pretty easily. Okay, you're doing Java support etc basically this information was added on demand. Because we have analytics engine. Well, thanks a lot to Daniel and all the contributors, but the data itself is being connected there on demand. What was mentioning that I've been actually working with open feature and open telemetry community. And I, many times I mentioned Jenkins as one of potential adopters for feature open feature engine, once it really becomes vendor neutral. And we could integrate it to get some statistics on feature flags in a more generic way, but it's, well, it's definitely well outside this particular thing. All right, thank you. Thanks. Any other discussion around prototype JS. So, the question is, what quality bar, what is the quality bar for releasing in a weekly. Buzzel I think you can probably best describe it there. My sense was that Buzzel's expect, well, I'll be quiet Buzzel I'd rather have you say it in your words than me say it in mine. Sure. I feel very strongly that anything with more than 1000 installations with with with very few exceptions should be green on this spreadsheet. And so, from my personal quality bars that there need to be a fairly strong justification for anything that has more than 1000 installations to be not green. And there are some of these exceptions like the translation assistance plugin which I deprecated. And there may be other exceptions to that. And but even, even the things that are below 1000. I still try to look at them on a case by case basis. And some of them are truly abandoned like, you know, HTML audio notifier is, I think it's like nine years since the last release of it so I feel pretty safe about ignoring that. I can't imagine anyone still using these audio notifications 10 years after this plugin was last released but that isn't the case necessarily for some of these others like open stack cloud or Oracle cloud infrastructure compute you know I don't know how many people are really using these. Some of them weren't released that long ago, maybe like two years ago or something. So, even for these I want to treat them on a case by case basis rather than simply assuming that anything less than 1000 is safe to ignore. I'd want to I want to try to make the best effort to either repair these ourselves or to contact the maintainers. Like I said earlier, some of the challenges in repairing these ourselves is that they really are integrations with third party software that are extremely difficult for us to test. So, I mean otherwise I would have already submitted a pull request for it. This offering detached plugin could still be a kind of plan B. Because for me the concern would be not these plugins per se but all the custom plugins everywhere we cannot really control. And you know for a fact that majority of them will be eventually test when these instances upgrade to LCS. I wonder whether we just approach like this previous removals ship a plugin that is immediately deprecated and at least have a plan B and at the same time have more freedom of releasing the thing once the quality bar is matched. There is no configuration attached to this. Unlike, you know, matrix job external monitor job J unit plugin they all had user data attached to them. I think it's a different situation. In this case, we put a detached plugin. So basically the plugin that is not bundled by default, not installed by default. Well then it's not detached. Then it's just a separate plugin like the one I wrote. Okay, it's my terminology mistake. But yeah what I meant is actually if someone experiences issues and definitely we are not going to fix all the plugins in the wild. So maybe just providing it as a simple plugin could save us a lot of time on firefighting later. Yeah, I'm off to minds about that because on the one hand it would give people an escape hatch we have we do have a project wide history of providing these escape patches. So, certainly consistent with our past our past experiences but on the other hand, I really don't like shipping these escape hatches, because you never you never know when it's safe to rip them out. And if you really remove it fully without having a skate patch, you'll get feedback very quickly if it's if something stops working. Whereas if you have the escape hatch someone might be using it and not telling you about it. And then you never really know when it's safe to remove defeat the old code, it effectively commits the development team to supporting the old code and definitely which is, which is which is not a non non zero cost that I'd read that I'd rather try to avoid. I have some mixed feelings about providing an escape hatch that there are pros and cons. Something else that I find interesting in particular with this project is how few plugins are even affected. Right. So we have like 2000 plugins total. And you found just 65 that actually needed to be changed, meaning the chance that a plugin is all else being being equal that a plugin is affected is fairly small. So, there's a good chance that we're basically talking about zero plugins. Yeah, most most plugins are doing extensive JavaScript on the front end, probably the most sophisticated one that I've seen was the UNO choice active choices plugin, which I didn't really know about but this plugin does some very sophisticated reactive JavaScript to add and remove parameters on the front end based on selections. So that was very interesting to me because I didn't know that we had stuff like that out there in the ecosystem but most most of our front end is extremely either extremely simple or implemented up with something other than prototype. You know, for example, all of Dr. Hoffner's plugins are using non prototype modern frameworks to do sophisticated things. So the the intersection between the set of doing fancy front end and doing that with prototype is indeed very small. Very good. Thank you. Any, anything else that we need to discuss with regard to prototype is like the next stop is a discussion in the Jenkins developer list about getting a rough timing on when and I think the puzzle is right that it's probably not in the next 12 weeks cycle, but 12 weeks after that, maybe a very, very good time, given the progress we see so far. Great. All right, thank you. The next topic was HTML unit three so whereas prototype JS is an upgrade of production code HTML three three unit three is test code, but it's widely used and quite important to how Jenkins does its testing. So the and the upgrade from two to three was a breaking change. So it's there are now hundreds of pull requests open and those pull requests are making progress through the system. So I've not seen anything that indicates this is going badly, just that there's there are an awful lot of things that have to change in order to do it. Any comments from others guiding on how's HTML unit three going for you. Okay, well in the tracking sheet again, a great help to have these tracking sheets on these large scale migrations. And this one. Okay Chinese localization plug in is the first one that's read. And then. Okay, yeah. So this looks looks quite promising. Most of the work is in the, you know, 20,000 to 1000 range. And that's, that's always the most difficult part of any of these ecosystem wide projects in the sense that there's there's a lot of plugins that are within that range where they are big enough to be actively maintained, but they are still widely used enough that we need to be can be somewhat concerned about them. So, yeah, there's, that's probably the area that that needs the most attention in here is that that range that we're looking at now of, I don't know, 20,000 to 5000 or something like that. And again, these are these are test changes, but they are potential barriers for other changes. If one of these plugins needs to update its parent palm, then it will have to do the HTML unit three upgrade in order to get the new parent palm. Yeah, very good. Thanks. Those are all the topics that I had were there any other topics that others wanted to bring to governance meeting today. Thanks everyone the recording will be available in roughly 24 hours. Thanks very much for your time. Just quick congrats tomorrow for being collected to the CDF to see. I'm not sure whether you mentioned it in the beginning but yeah. Thank you. Thanks very much.