 Hi everyone, welcome to the Jenkins governance meeting today is November 4th, we have several contributors on the call, me, Mark Waite, Uli Haffner and Vip Haffner, so we have a few topics and agenda today, we will firstly start from news and various ongoing events in the Jenkins community and we will talk about Jenkins elections, Mark has an update about the PFA video, I have an update about Trademark, which is a no update, we will get there and also we wanted to quickly discuss, search for Jenkins IO and our options there. Okay, let's start from the beginning, so for Jenkins elections we have announced 2020 board and officer candidates, so you can find the list on the website, there was a announcement about that, you can see that there are nine candidates for governance board, you have two positions after election, so if you want to support any particular candidate, now it's a great time to actually register so that you participate in the elections starting next week, so there is a big register button here, you can also find ways to register here in the bottom, we will also have elections for the Jenkins release officer, we have three candidates at the moment, for the rest of the officers after the initial discussions with the nominated contributors, we ended up with only one contributor running for the elections, what it means that there may have been more contributors, but then they decided not to compete in the elections and finally we got four uncontested officers, so elections will happen on the photo positions. Okay, so key dates, November 8th voting sign up is over, so it's this Sunday I guess and there is still some time to register, so again please do so and after that we will start communicating with all contributors so that everyone can participate. Okay, any questions about the elections? Okay, so more updates, we have recently had Jenkins releases, Mark would you like to summarize them? Sure, 2.249.3 released today, it's a relatively small update compared to 2.249.2, two regressions fixed and one additional fix, we've released 2.264 with the tables to divs implementation and we've got some additional upcoming bold changes coming, oh and plugin security release, good observation, yeah. Yeah, I also forgot about that, so yeah important to note for weekly releases, there will be a period of instability, maybe a few weekly releases, because we have a number of changes coming down the line, so Mark has a summary there, please be ready to that. Right and we're looking forward to those, each of those is a good step and a valuable step and today we had an announcement of plugin security releases for several, particularly if you're using the Active Directory plugin, please upgrade. So yeah it's here, you can see that the list is quite big, so it's not only Active Directory, Kubernetes plugin, Kuryl plugin, Subversion plugin, all static analysis plugins, you find this incorrectly, the new warning synchro stack is not affected, right? No, it's only the old ones, because nobody is developing anything, so. Yeah, but all of them are marked as deprecated at US, yeah. Yes, well and proudly we've removed them, the old one from ci.jakin.idol. Okay, so still, if you use deprecated plugins, it's definitely time to upgrade, because you won't be providing security fixes for the new, for the deprecated plugin. Okay, so Mark, would you like to comment about these changes? Sure, so where Jenkins has used for many, many years an old version of a security framework that we're now upgrading to replace with current version of Spring Boot Security, and very grateful to Jesse Glick for doing that work, he's doing that work through a Jenkins enhancement proposal, and it's looking like within the next one or two, maybe three, three weeklies we should have that in, it won't be visible to users of the LTS until March of 2021, most likely, but it's looking very good and very, very positive. Yeah, and this change includes incompatible modifications in APIs, so there is ongoing fixing for plugins, and the users of LTS may actually get the versions with updated plugins, but it shouldn't impact the behavior according to the JEPs. So, yeah, in ideal situation, there should be no impact. Yeah, there is a lot of other changes happening here and there, but it's nice to see that the technical depth in our dependencies, because each of these dependencies have been a huge maintenance button for us, so once we get them over the line, we will be able to pre-adopt new dependencies, which have been blocked, and also we want to need to care about maintaining our forks. Yes, the whole process of unforking, deeply grateful for Jesse's work, and Felix's work on the jQuery upgrade. Those of us who are users need to be aware that the changes are happening and be ready to report issues as we detect them. Okay, yeah, so any other news to share? Okay, then let's move on. So, Jenkins selection status update. Again, we have the blog post, maybe a few updates there, mostly to highlight the registration button. Also, as we discussed at the last governance meeting, we spent some time to facilitate the registrations, so most notably, thanks to Olivier and Mark, we sent emails to 2019 election participants and to plug-in maintainers, so it led to putting the registration numbers, and hopefully, we will get more by the deadline. And yes, this is the main update. We also started doing pre-tweets for announcements from candidates in Twitter, but we didn't do it consistently. Not every candidate even has a Twitter account, so it's just additional assistance here and there and improving visibility. So, if you haven't registered yet, please do so, because again, the deadline is August 8th, and almost every Jenkins contributor is a digital vote. So, if you did any contribution before September 1st, you're a digital and not only quad contributions count, so if there are any reports, etc., you can still vote. Okay, any questions before we move on? Okay, moving on. So, if you have a video. So, this one is still on my list. Apologies, I'm back. I've got to do it still. We had the agreement two weeks ago. My apologies, I haven't taken action on the agreement yet. The agreement, I believe, still stands. It'll be part of the Jenkins IO route page, right below the jambotron. Thank you. So, you also have action items on me from the previous meetings about trademark page updates. I still haven't finished the pull request. It goes stuck somewhere in the middle, but yeah, definitely by the next meeting it will be addressed. So, just quick update. I guess that's all these action items we had before. I had a quick update regarding a web search for Jenkins IO. I'm not sure whether it's the best venue. I will just summarize with the discovery status. So, yeah, as you know, we don't have a search on Jenkins IO. One of the reasons is that they were concerned about using any particular search engine because of vendor neutrality and because of data collection. So, at some point, when we were discussing to the contributor summit, there was consensus that just we don't want to go to use a standard engine like Google's one at the same time. If there is a search engine which we could embed, which we could use, which wouldn't collect the data, et cetera, it's something we would be willing to do. I spent some time on trying out the engines available in the market. Actually, there are not so many of them, but I found one with a potential sponsorship opportunity which we would be able to put. I was about to do a presentation on the documentation seek, but yeah, finally, the situation that we had a quick discussion about sponsorship, but we didn't have the agreement so far. So, it's not an option for us. And as we discussed that before, the main reason is that we still have difficulties proving that we are not a commercial organization. That's why sponsorship is available for some profits, and yeah, there is a nonstop level there. So, my question to the governance meeting participants is, would you like to revisit the options with search parts which actually collect user data? And for me, I don't object to that collection. I would object to having a search on our page inadvertently display something from some other CI system as an ad or something. That would bother me. In my case, I'm using Google to find something on the Jenkins website anyway, because it's hard to find anything without search. So, there for me, nothing would change in principle. What about others? I think it's really helpful to have a good search, because now the Wiki is dead, and I used the search in the Wiki a lot, and it would be really helpful to search the developer documentation on our webpage using a good search. So, Uli, I didn't hear an answer to Oleg's specific question there. Is it okay if we use a search engine that collects user data with you? Yeah, okay, sorry. I thought the question was, first, if I think the search would be good, and yeah, I don't care about that. I don't know where I lose my data in every form in the internet today, so I think it doesn't matter on our page. It's good for me, yeah. A cram, any opinion? It's fine, it's okay. Yeah, on our side, so we are joining also the question about the Jenkins operator. Moving, yeah, this is the point that we have added to the agenda, so this is about the roadmap in the future of the operator. We have raised an issue already like, it's almost two months ago now, and we would like to know what we can do about that. So, we will get to there. Let's just finish the search topic. So, if there is no more input there, so what I can do, I can do a new prototype, let's see, for Google search or for whatever other embedded search. If you want, I can put bin to there, but yeah, we'll definitely do that, and then we can just review it, maybe at the next meeting, and see whether it's good enough. Yeah, thank you very much for being willing to do that. Mm-hmm, well, I wanted to do it for a long time, and yeah, since there is a lot of free user feedback coming from the lack of search, and yeah, actually the prototype I was doing, it was able to collect from multiple sub-domains. So, for example, the same search was working for the plugin site and also for the main site, and just for fun for Jenkins, it's the way I go. Yeah, I'm not sure what I will be able to reproduce that, but it has some advantages. So, for the plugin index, you can definitely search here, but there's an assumption that a lot of documentation is injected on the plugin pages now, which haven't integrated the search engine working across multiple sub-domains, so it would be useful. Maybe even two searches, one for user documentation, another one for developer documentation, but it's more complicated. Okay, so any comments, questions? Okay, then Jenkins operator roadmap, they will try to find a mailing list thread, so somebody will summarize the service. And so, this one. So, again, the public conversation here is just the tip of the iceberg, because there was a lot of various background discussions. So, it started from hard to make it a proposal for open governance of the Jenkins operator project. So, the reason that the previous maintainers with Toshlap, they have been inactive since May or even April this year, and there is a lot of start-to-requests for the project, and basically there are obstacles which prevent the people from contributing there. And there was a proposal to actually produce an open governance model, which would include multiple parties, so that by default, it's with Toshlap, Red Heart, and it's governance board, so that there is no at least three entities to break a tie if needed. And this proposal was sent to the developer mailing list after that one of Jenkins board members, Alex Erl, it took an action item to reach out to the Toshlap director. Alex did it, and we got a response at a more than one month of waiting companion that Toshlap would be interested to continue in the open source, and that they intend to respond. So, the service update from Alex was on October 21st, so almost 30 weeks, and since that we received no communication from Red Heart staff, so I think we have to think again, but ultimately it will bring us to the issue what we do with this project, because we spent two months without any clear progress, and yeah, this is definitely a good talk discussed today. Yeah, actually also there are some users who start to be upset, so at least there is one issue, someone asking what's going on in the project, and why is it still not maintained and answered regarding issues. So, that started to be like indeed a bit of an annoying situation, and on the other side at Red Heart we still continue working on our four-color project, so for a while we have maintained compatibility with the end-to-end tests that were initially developed by Toshlap, so we were sure that we have maintained the same future, but since a while ago, since maybe one month or something like that, we started to operate a master refactor on our codebase, which basically breaks the compatibility with the original one, so we were first to do that because we have to move forward with refactoring and developing new feature, and yeah, so this is the current situation. Yeah, so we discussed multiple options in August, because our main preference remains that sure that the current upstream works fine. We have an option of creating a new upstream, especially if there are breaking changes, because at some point in the Red Heart team I made a proposal about the Jenkins-operated roadmap, just a second I'll change the screen again, but yeah, from what I understand this proposal basically got no response from Toshlap, right? This one, so the only responder is basically me, and yeah, so if we assume that there are major and potentially breaking changes, what we can do is say that, okay, there is Kubernetes operator, and there will be Kubernetes operator two, basically coexistent and parallel. It has obvious disadvantages because it will skip to the user base, it will create confusion, but at the same time it has a chance of becoming a new, more healthy upstream. This is what we can do basically even now. I will also, I can also ask Alex to interrupt about this point, Oleg, because we have discussed already all the options, and I remember that my own opinion was to indeed move to another fork and create our own version, but it has been decided, I mean, at Red Heart level with the product management and so on that we prefer to remain with the single community of users, and so this is what led us to propose a new governance model which is more open source compatible. So yeah, changing this direction would be also a huge effort for us right now, and so yeah, we have to find the solution which is suitable for maintaining the community, and at the same time, like the project being not active for several months, that's completely normal that there is some changes in terms of compatibility and that we cannot maintain the same future such long, especially that the APIs were on alpha stage, which means as an operator perspective that being alpha, we are still able to change the API and do breaking changes, actually, which would have been different if the API had been published in beta or stable already, but this is not the case right now. Yeah, so there were some changes and integrations from Thomas? Yeah, actually it's more about documentations and probably the Helm chart change, some changes on the Helm chart that installs the operator, I think this is that the last changes that happened on October. Okay, so yeah, I will just follow up on the thread we have with the Jenkins governance board, because we have a considerably longer thread there, which is not public, yeah, let's see whether we could proceed. Okay, apologies for that, it takes so long, but ultimately we cannot get a response, and at some point we will need to think what we do, because with the assumption, so if we don't get a response, neither from Thomas, who is officially a maintainer, as far as the Jenkins project commission or from Virtus.Lab, which is de facto the sponsoring company for the current upstream, then yeah, in the Jenkins project, we have a few options, but ultimately we don't have a process of transfer and permissions when a maintainer is actively against transfer and permissions. So yeah, it will be a tricky situation, and I think that finally we will end up voting at the governance meeting, but yeah, I think that taking the release, it's this way becomes more and more probable. So I suggest that we do the last attempt, and if we don't have progress by the next meeting in two weeks, then we actually start a formal process, which is not clear to me, but yeah, just looking at whether we could transition the current upstream. Yeah, it's my suggestion, I'm not sure what Mark and would you think about that? I think that sounds reasonable, so Akram, it seemed that your position, your strong desire is to retain the current artifact ID and thus the current community, and therefore you would need to be allowed to take maintenance of that repository, co-maintaining with Virtus or sole maintenance for a new set of maintainers, right? I think that's what you're describing. Yes, that's what has been requested by the Global Red Hat team when we discuss this. So we still want an open governance model, we want to maintain the same artifact ID, so-called artifact ID, because it's an operator, and we want to be able to federate the existing community and support them. One potential concern there is that basically we have no control over the operator hub, so what it means that we can transfer permissions on the Jenkins projects side, but all operator hub, even if we come to a decision on the Jenkins side, I'm not sure what will be the process there. So for operator hub, I don't know also completely the process, what I know is that it is maintained also by Red Hat people, and we didn't want to interfere or to bypass, like requesting the permissions or the rights to commit on the on the on the files to deploy on operator hub. So we just keep this one as is, but I would say that if we have an agreement from the community, then we can ask for this one, I mean, but the most important is to have an agreement and a proper decision, I would say. Okay, what's your opinion? It's hard to say, I don't have any knowledge in that topic, so I really don't know. Okay, so let's continue in the governance about my increased, because we might definitely need some advice, probably even from a continuous derivative foundation on this model, but here we have two weeks until the next meeting. So let's see whether we could get everything in place by this time. Okay, but yeah, thanks for bringing up this topic, because Jenkins Kubernetes is a really important project for the community, so we definitely need to resolve this issue. Anything else for today? Any other topics? Nothing from me as well, then we can close the meeting earlier. So the next meeting is November 18th, I guess nothing specific is scheduled on this, well, it's cube content, right? But I guess we do the meeting, can you wait? All right, and I will miss the next meeting, but go ahead. Okay, so then let's just do that. I will probably be at cubecon for a while, but yeah, governance meeting shouldn't be a problem. Okay, then I guess that's it for today. Thanks everyone, and I'll talk to you later. Thank you everyone.