 the cloud. Okay, sorry. Recording is started. Thank you. Yeah. Hi everyone. Welcome to the Jenkins Governance Board meeting today is August 26. And we will have a discussion of several topics. So we have six contributors on the call. And yeah, based on our agenda, we will talk about some news, then maybe have a GitHub relationship proposal from Daniel. Jira upgrade discussion also preparation to the next board and officer elections. I sent up on the current community events. I wrote my preview, which we tend to related to this meeting to follow the JEP 14 process. But again, it depends on how much time we have. And co-governance discussion. If we get time, let's discuss that. And yeah, that's all topics we have on the list. So does anybody have any news to share? This was brought up in this week's info meeting. But I think we can mention it here as well. We are now serving our Jenkins core and plugin downloads via HTTPS. It was not a big of a problem as this sounds, because Jenkins downloads were verified by Jenkins, and it has actually fairly elaborate structure to ensure the download integrity. But now even that is even problems like corporate proxies rejecting any outgoing HTTP URLs and stuff like that are no longer a problem. So basically it's modernizing commitment infrastructure, right? So we solved both Infra 160 from 2010, as well as Infra 266, which is not a lot newer. Okay, so yeah, there are all the issues and then one which is a reference from the roadmap. When we were discussing infrastructure roadmap, we took quite an abstract topic because it includes not on the resolvent mirror beats, but yeah, big thanks for doing that. And Daniel, if you could update this epic and tickets today, it would be awesome. But yeah, I guess our next step here would be to actually have more mirrors, because before we were blocked due to lack of HTTPS on mirrors. Now we can actually reestablish the mirror infrastructure. Additionally, you will also probably solve the problem of downloads not being available for the first hour or so after a plugin is released. So that costs some problems, especially with new Jenkins installations whenever new releases were released of popular plugins. Right now this costs some more money. Tim will know the details there. But for now it is resolved until the bill comes to I guess. And I am delighted to have proven what Daniel described. I downloaded a plugin that had been released 51 minutes prior and no issue. Thanks, Daniel. Marvelous result. Yeah, great. And yeah, thanks a lot to Daniel too, Tim for working on that. It's pure infrastructure issue, but it should help our users a lot. Our users a lot. And yeah, combine this package Jenkins installations on fast, immediate, hopefully downloads will be much more stable. Okay, other news is we had a security release. So it was a few days after the previous meeting. Then he is notable to mention there, Daniel. Nothing really notable there. What might be more notable is the one we had published just five days later. Problem there was that the JETI integrated servlet server had a vulnerability and we just updated it as usual in the Jenkins weeklies, but not in LTS. And when we finally got around to investigating it in more detail, we identified that the vulnerability is fairly easy to exploit in Jenkins. So we made the decision to publish an LTS only security update that is unscheduled and pushed it out basically as quickly as we managed, as quickly as possible. The weekly releases were not affected. As I said, we did a routine update there. It was only LTS. I think it went overall fairly well. Since we went from identifying the problem to the release in two days, two weekdays. Yeah, thanks a lot to that. Another issue, a change which we integrated is also Alpine images update, which was a kind of one cover deal. Yeah, thanks to RxMark and other contributors for hand-in-bed, because now our Alpine images officially run on Adobe OpenGDK with the recent versions of Alpine Linux. So it should be much more convenient for users. I guess our next step is to update all other images to Adobe OpenGDK. Yeah, I think we have a key approval for that. Yeah, there is a pull request. Yeah, package structure changes, etc. Okay, and another thing which was mentioned, right now we have a, I guess, a branch for backporting for the next LTS baseline, right? Yeah, this, I guess this, right? So the branch is ready. We are slightly behind the release candidate, but yeah, I guess we could get it out tomorrow. And then we will go on track, right? But yeah, the branch itself should be ready. There are some discussions about, for example, dotnet framework patches, etc., but I think that overall it should be stable enough in the current state. So any other news to discuss? I guess no, and let's go to GitHub for relationship. Daniel? Yes, I proposed a few days ago, a few weeks ago on the dev list that we clean up the fork relationships of repositories in the Jenkins CI GitHub organization. We have a lot of forks in the organization because that is how the hosting process works. Someone creates a repository in their own account and to host it in the Jenkins project, we create a fork using the GitHub API. The problem is that the expectation is actually that the repository in the Jenkins CI organization is the canonical repository where all the work and collaboration happens and it's supposed to be specified in the POM and so on and so forth. And so my proposal is to clean this up. I've confirmed with GitHub support that if both the Jenkins CI organization owners and the owner of the upstream repository agree, the fork relationship can be inverted and we can alternatively also cut the fork relationship which would make the Jenkins CI repository as well as every repository that forked from Jenkins CI its own, I think the term on GitHub is network. And so this is my proposal of how that would work and I've also prepared a script that you can see a few paragraphs down a link to the Jenkins CI documentation where there is a list of all of the forks in the Jenkins CI organization and my proposal is to reach out to the forks that have repositories forked into Jenkins CI and ask them to contact GitHub support to get the relationship inverted and for those that don't react or refuse, we would end up cutting the fork relationship. Additionally, I will spend some time to identify upstream repositories that are that actually have things like issues and pull requests so where there would be some sort of loss of data involved if we did that, I expect that that is actually the minority, a tiny minority of repositories but I don't have that data yet. So in this meeting I seek approval to go ahead with the plan. All of the feedback that I received on the developer's list was universally positive and our know even brought up our he experienced problems because of this fork relationship because it's confusing and automated tools do not handle it really well. Isn't build for pointing deprecated? Anyway, it's off topic. Yeah, it's deprecated. Yeah, one question I had. So we are talking about all the repositories, not specifically plug-in repositories, right? Mostly plug-in repositories, there are a few others like plug-in POM where there is a fork relationship that also doesn't make sense but we do have some repositories that are actual forks like I think the repository called extreme fork is deliberately a fork or at least it was a while back and so yeah it's basically every repository that is a fork because that's how the hosting process works and not a fork because it makes sense structurally. And it involves 30% of our repositories, right? So it's 810-ish in the big number. Yeah, I expect to write a script to just look for upstream reports that perhaps have diverged history and I have some plans to clean that up and I will just skip any repository where there would be problems that would result in something akin to data loss. Yeah, so it would be great. My question is do we have enough information to vote? I guess on this call everybody has already voted except Alex and I'm not sure if you want to participate in this vote but yeah if you want you're totally welcome to do that, it's up on a meeting. I don't want to impose it also, I'm most a listener but if I get a vote I obviously would use that. Yeah, you get a vote, everybody gets a vote. Yes, so Alex and Marc, what do you think? Yeah, I'm a plus one. I would like to investigate if we can change the hosting process so that we don't have to do this in the future. We had discussions in the past of trying to do transfers for repositories instead of forking. So I think it'd be good if we reviewed that so we don't have to continue to do this in the future. So that's one option, another option would be to not actually use the GitHub feature that creates a fork but create a new repo and just mirror all the commits and branches into it. This is for example what the Jenkins security even does for the private repositories that we have. We just create a new repo and mirror everything from the public repo and then we work on security fixes. The result should be the same except in the case where it's an existing popular plugin. If it's a plugin that already has forks and stuff then we will have two independent networks which will be sort of weird but I think we can get most of the way there by just creating a new repo and mirroring all of the branches into it and manually doing the repo transfer perhaps. I'm not sure how easy that is to automate for the minority of cases where we want to retain stuff like existing issue trackers and pull requests. Well it doesn't have to be manual because GitHub supports transfer requests now. It's not the tricky from user interface but from API you can initiate the request transfer even if you're not a member of a GitHub organization now. Oh really? Well I mean we can initiate the transfer I guess via the bot in our current hosting process and then they would just have to approve it. A quick question. The repository transfers can we request an inbound transfer or can we only or do does the person requesting the hosting do they have to request a transfer from them into Jenkins CI? From what I remember the little one but yeah you'd have changes quite quickly so might be this kind of option is already available sort of the first one. The second one looks the second one seems to be a bit cumbersome so I'm not sure how practical that will be in practice but we can we can keep that in mind. Okay I'll go take a look at the APIs and see what's available now. So for what it's so I mentioned this in the thread on the dev list I see these topics actually as almost independent because we never wanted the fork relationships to begin with and for the last year or two we actually told people or asked people in hosting requests to please delete their repositories which would end up hopefully making the repository in the Jenkins CI organization the canonical repository from which they can fork again so in that sense we never for a long time we didn't actually want this relationship and we've recognized that it's a problem it's just that the tooling hasn't caught up and I don't see a reason why one would necessarily block the other here so I can go ahead with the fork relationship cleanup of existing repositories even while the hosting process still works as it does and in the other direction we can fix the hosting process to not create forks in the first place even while I'm not yet ready to clean up the fork relationships. Yeah I agree with that and yeah we can read it separate here I created an action item for you Alex. So Samak what's your opinion? I'm also class one for it on one side from ownership perspective I think all communities I'm involved in follow the same that the ownership of all those repos need to be with the with the main project Jenkins in this case and having Jenkins fork another repo or vendor repo thing that kind of goes the opposite direction and the second one is to an outside looker especially for smaller projects the direction of contribution becomes misleading when the repo is somewhere else and is forked into JQCI where they should get involved in where things happen first and then propagate to the forks for anyone that is deeply involved in the project that won't be misleading they would they would know exactly how this works but if you if you're not you're not deeply familiar with that just getting involved it's not that obvious that all of the work happens under JQCI repos and then they get cherry picked by the repo that was actually originally forked right so definitely for it. Thank you. So I guess we have an agreement to move forward. Anything else on this topic? Do you have great progress Mark? So the plan has been discussed with Linux Foundation. I have a number of action items. I've got to get on those action items. They're related to getting a backup, getting SSL access, etc. This plan is accessible publicly so if you've got comments on it you are welcome to make those comments. The hard stop deadline is November 28 and we'll continue working on it. Just to make sure we continue this migration without changing content management right? That is correct. That was a mandatory and the Linux Foundation team confirmed they can do that. So we do not have to change identity management. It doesn't block us from choosing to change identity management sometime in the future but for this transition it will not require a change of identity management. Great. One less service to maintain. Anything else on this topic or action item for everyone who is interested to take a look at the plan? Daniel, Adek, Zula. We need to read the plan first. Okay. We don't vote on anything specifically right now so it's just a status update. Right. Okay. Then if no other comments moving on. Okay. 2020 born as an officer election. So I started the discussion yesterday in the mailing list. So this discussion basically submitted in advance because assuming that we follow one election interval for officers we expected to hold an election in November so that the results are effective in early December. But still there are some topics to discuss because firstly the elections is a bit complicated and second day to Southern Bank election was quite complicated from the implementation standpoint. So there are some discussions how it was done. That is also public retrospective we had for the previous election. Basically this is what we created in December at this. We did some discussion and agreed on some items but we haven't implemented them because the election was one year ago. So probably time to actually revisit that. So yeah. I'll put the feedback to three groups. Voting registration process. This last year it was quite difficult because we needed to send emails to 100,000 accounts also to get back on send. There were a lot of concerns about the legibility etc. Then generally in the legibility we have issues from two sides. Firstly we had no way to verify various technical accounts and generic accounts. Yeah we know that there are accounts owned by kings. We know that there are test accounts like 15 accounts of 40 a year and something like that to provide an example. At the same time we had a question actually whether our voting is inclusive enough because we are relying on Jenkins LDAP database but currently you don't have to be in the database to contribute. You can just use github, github issues, github portal request, you can write blog posts, whatever, stack over flow, mining please etc. And you won't be eligible unless you create a LDAP account for the election. So these main concerns and also basically a lot of manual stuff. So to address that I started pulling together a process proposal. Basically the idea is to change from email notifications to all registered users to public sign up with post-factum legibility verification. So what it means is we send emails basically to mining please also in social media etc. and anyone can sign up. Then we do verification based on providing data. So we will ask users to provide github accounts, gira LDAP accounts and if none of it works reference to a public proof of contribution. And if one of these ways is confirmed then a voter is considered to be eligible. Obviously then tools to measure pain points is firstly how we automate verification assuming that there will be hundreds of voters like last year and how we do manual checks because last year we avoided manual checks just by providing an escape hatch. If you're not in if you didn't get notification please send us a message, I believe we did, but this year it will be more likely with public announcement and public sign up that there will be more users submitting requests and putting public links to some things like LinkedIn profiles who knows. So but still I think that it would be one of the ways to go and I seek feedback from contributors. Again no plan to vote on anything today. This is just up for discussion and you can see that there is already a bunch of comments floating in. But yeah if somebody has experience with public voting systems and sign up, if there are some tweaks how we could automate eligibility check please feel free to comment. I like I had one question. When would you propose starting the Google form to collect those who would like to vote? So assuming we hold a vote in November we should start to sign up in October. It doesn't have to be October first, but definitely it should be at least that few weeks to sign up. Yeah this is something we can define. So again I just started the document to kick off the discussion. If we take 2019 process, so I'm just going back to some introduction and implementation. Well it's partially in the mailing list, partially on the website. But yeah here was timing proposed by Tracy. Yeah retrospectively we know that this timing didn't work because we had issues again with sign up phase. We send all these accounts, we create configurations in grid properly, we're collecting this data. But here so we had the mination phase and yeah here we don't really have a voting sign up at all because it was a kind of basically prompt implementation during the voting. So I'm just trying to find it, but actually sign up was just implemented right on the flight. And I'm not sure how much time did we get to something like two weeks at this point. I'm just worried that with the amount of verification so we may need to do this verification to get which we don't know. So I would say we give ourselves some more time beforehand before the vote. I can close the sign up certain number of weeks before and then the time to do the verification and the actual voting. Okay so basically Alex what you say that two weeks might not be enough for sign up and for verification as well right. We can just set some ballparks. For example if we say that sign up time four weeks, well four weeks might be a bit different as possible. And yeah also voting time. So for example if we say four weeks here and say two weeks here and two weeks verification, it means that we would need to start on October 1st to hit the timeline. Why do you want to serialize sign up and verification? Yeah we can somewhat parallelize it. I think we will need several weeks. Okay so one week or so right. Do I capture it right? Try to state as much as possible. So yeah basically I reduced the verification time to one week to address Daniel's comment. Is it what you were talking about because I didn't get it. The audio breaks. Okay so what I suggest to do is that we keep discussing it in the Google Doc and what we finally need to do. We need to merge this kind of proposal which is a div. We need to merge it with our actual process description one we modified last time so that we have a formal step-by-step process. This is also one of the retrospective feedbacks because yeah from our side participant who wasn't involved. The process wasn't fully transparent last time. We got this feedback from multiple contributors so if we just have step-by-step guide with all these phrases listed and with the assumption that we can deliver on this time frame. I think it would be the end goal. So for now I propose to keep discussing this Google Doc and then somebody will need to move it into a single board direction process documentation. For that there is obvious reason that yeah what I communicate to developer will be basically until September 17th or so. If we start working on that at this time would we hit the timeline or should we continue working on that in the next weeks? Yeah, which both? Yeah, so Alek, can I treat comments? But yeah I think let's just continue in the developer monoclist because my good feeling is that we actually need to facilitate it now if you want to feasibly meet the deadline of December announcements if you want to change the process. If we just use the same grid process like before if we have a bit more freedom. But yeah, again I'm not 100% sure about that. Keep talking, sync up with the next governance bot meeting graph. Okay, sorry it took a while but yeah any feedback will be appreciated. Anything else on elections or should we move on? Because yeah, there's Alex in the car. I'm not sure we can discuss efficiently right now. Okay, incoming community events and programs. So just quick update what to keep in mind. So Google season of docs basically we've accepted one mentee. So we'll have a project focusing on Jenkins on Kubernetes documentation and this scope includes basically everything with regards to Jenkins and Kubernetes including plugins like Kubernetes plugin, including Helm charts, including Jenkins Kubernetes operator and other bits. Again, this scope is a bit abstract right now because one of the parts is actually define a final plan and mentors will be working on that together with mentee. But if you're interested please join the Google season of docs channels because yeah the project topic is set and I guess the Jenkins on Kubernetes is quite important from the community various standpoint. So hopefully we will be able to use this opportunity well because yeah what we get is just an experienced technical writer contributing to the project for four months including funding and yeah let's try to get best of that and yeah thanks to mentors and to all candidates who applied because yeah this year you had I guess 10 plus candidates applying many of them have contributed a lot to the Jenkins project and unfortunately we were unable to accept everyone because as a first year organization we are limited to one slot. But yeah that's why I have community bridge for docs in the bottom. Actually I can just move it up so I wanted to organize it but yeah I'm not sure whether I have any feasible bandwidth to derive this topic because it actually boils down to two questions firstly budgeting and secondly mentors because we have no problems with mentees thanks to Google season of docs there is a lot of candidates and actually I wouldn't even look for more candidates at the moment but yeah the problem that we need to mentoring teams for the projects is to mentor us for a project and also we ideally need a kind of stipend and right now as we know we are quite low on the budgets we have started finding proof of concept but we haven't started pushing it to find raise money so unless we find a corporate sponsor right now yeah budgeting is also a problem but well budgeting is something we can solve mentors is more challenging so if anyone has any ideas or if there are any particular interests including company interests to get some areas the community that is contact us because yeah this is how we get the projects running budgets yeah we can shake some trees okay so yeah but yeah main concern about that that even if you run it it will be next year I don't think that we can feasibly start the project in the next months taking all other requirements okay October 1st this is something we cannot start next year because it starts in October whether we want it or not so again we need a kind of steering committee we've been participating in October 1st for a few years before and it was quite efficient so last year we had 127 unique contributors among them around 60 first timers in the Jenkins organization and on average first timers contributed three pull requests of different quality but yeah it was mostly about documentation updates and some additional features including pretty big Jenkins core features so I would say that overall it was quite a good experience for the organization and we should keep doing that the same time the question is about format just last year we tried to organize local meetups as a part of hard for breakfast for breakfast that organizes local meetups as well obviously this year it's no go option so we need to do something virtual like we did in previous year we had a kickoff sessions like this local events yeah so we had a grant opening session where we had presentations about how to contribute we also had October 1st results so this I guess it's kind of minimum format but yeah we could probably at more meetings online meetups and contributed meetups in the middle for example similar to how we did your UX hardfest in May so here we had how many meetups 10 or so yeah this what we published here and actually we had more at Hawk once so it really depends on how many worldwide we have and how many maintainers joined the initiative because yeah these local events depend on future projects so this is the least we had in 2019 so there are still some topics we could move on so for example Jenkins warnings and J plug-in I guess would you be interested to document something I'm not sure what was the experience for you would last year do you make contributions and not really just some newbie contributions but I think it was only five or so and these were mostly my students so right maybe this is not the best topic yeah for configuration was called to be definitely good contributions we got contributions for Jenkins for or Jenkins file runner also we had topics like plugin documentation immigration which attracted a lot of interest I guess this year we can keep that we can also terminologically enough because we have this project documented on the documentation sick page and we could probably just scrub these topics and find the initial set but yeah I guess we will also need to promote it among maintainers so that we have more topics on the table the docs office hours has been adding systematically going through and doing triage Jonathan Marais and Vlad Silverman of both and working both kind of topics so I think I think we've got good potential for at least doc side many opportunities that are well vetted by the time we reach October 1 okay so online meetups featured projects and yeah also unit organizers so does anyone want to be in the October 1st working group this year yes okay and yeah I think we can send a message to the main increase so we could get some usual suspects joining so hopefully we'll get some by the way right I think that for instance Vlad and and Jonathan may be interested in being part of the organizing so I will bring it up to the office hours with the doc stick as well okay let's see okay so I think that I will send a message to the developer Malin Chris to start coordinating with it oh like you want me to take that given how loaded you are I can you can certainly delegate it to me in a big chunk of them will be docs thank you yeah yeah I will do my best to help but yeah take my availability in general and yeah thanks a lot okay so yeah moving corn DevOps Vault yeah quick update Alice is looking for volunteers because again you will be doing kind of the Jenkins stand DevOps Vault this time DevOps Vault is visual so you don't have to go anywhere the same time yeah we still need to mend the booths etc and yeah all contributors are welcome and pretty much the same for cd-con so for cd-con the format is yet to be decided so DevOps Vault is September 22nd 24th if I recall correctly this October 8th 9th but yeah for cd-con Jacqueline Salinas and cdf they are looking out for Jenkins representatives yeah if you're interested please join and focus and outreach sick meetings yeah so I guess summarize us all community events we have I'm not sure whether it really makes sense to even touch roadmap preview because yeah we had quite a number of topics today so maybe we could keep take it down the road especially since the roadmap is pretty much up to date we remuted in the middle of July is it fine with everyone okay so yeah okay so Samak would you be interested to talk about governance-spirited governance yeah absolutely is it one hour to call so like 10 minutes we can go slightly over time but people might start dropping I'll adjust to that like time I have the low detail so the background is that we as Red Hat we have a number of engineers a team that works on the Kubernetes operator for Jenkins the Red Hat is an advocate for operators on Kubernetes in general and since we have a lot of customers that run Jenkins on OpenShift we want them to use the Kubernetes operator instead of just deploying the images to say they get much better experience with configuration of Jenkins and backup and all those capabilities so we got involved in it about a year ago and the initial work was done by VirtusLab they had done a great job at bootstrapping this as a part of consulting efforts that I think they had done with that reverse project setup that was discussed that the repo is active VirtusLab is forked on Jenkins and we have tried over the last year to like to collaborate or we have been collaborating with VirtusLab I think the problem we have recently had throughout the time is that there is an on-existing path to to a committer status on the on the projects to VirtusLab is a sole committer on the project which makes it difficult when a single vendor is the sole committer on it so becomes a unnecessary level of political based on the uses that VirtusLab has of the operator and their customers which is understandable but like it's not healthy for the operator itself so the way we are in a similar situation as Red had it very of the projects that we are involved in open source project we are invested in the success of the project and then we drive within that community things that our customers care about but also we are relying on the other members of the community other vendors to vet these requests right to make sure that these are sane these are good and and that that's how it will help the community with work when it's a single vendor then it becomes a place for the interest of a single vendor as well so a lot of the PRs they're new mayor they're like more than 10 PRs the thing that they've got rejected so far and the rest of them takes months is to to get to get marriage because of the pushbacks of not being in line with what VirtusLab customers want and they have been living this reality for about a year what recently has happened is that VirtusLab does not have they don't want to spend much time on the operator anymore they don't have the resources the main committer had unfortunately some health issues and while that person was gone we were completely in the black because no one else can commit anything like till he came back he's feeling better coming back but the recent communications that they have had and I'll ask my team to send the email again with the longer background to the to the public mailways so you have more more background on it is that they are they have they're changing their priorities has changed and they would not be spending much effort on the operator which is fine this is obviously every every company has different priorities so this is nothing unusual there what is unusual is that they they want to keep the sole ownership of that project which that that's the issue real that that you they don't they don't have the resources and bandwidth to be active on the project anymore and they don't want anyone else to have committer right which means the project essentially gonna die in this in its form and they have they want to work on the project on their internal repo which is right now the main repo so essentially taking the project back into a vendor project which is a step back in our opinion for it we get a lot of good feedback about the operator both on Kubernetes and OpenShift so we are invested in they're hoping that more vendors get involved more individuals get involved and this becomes a thriving component of the Jenkins community but the current situation seems that this is not going unfortunately in that in that direction and and we have tried to converse with Virtus.Lab for a number of times to address this because we like the communities formed through the members of the community doesn't it shouldn't need to be like intervention from outside to to fix that but unfortunately that didn't give any results either so this has been our last resource to reach out to Oleg and raise our concern and situation to the board see if there are any paths to to get more people involved we don't want to redhead end up in that situation either so a Kubernetes operator in that situation I mean to be the sole owner of this repo right we want the Kubernetes operator to have through the community guarantee the survival of the operator regardless of if there is a redhead tomorrow or Virtus.Lab tomorrow or not so that that's really what we want from that community so the ask is basically we have had a couple of chats with Oleg as well the ask is to see how we can what are the paths to turn the Kubernetes operator for Jenkins into a more like a a multi-interest or multiple sides and vendors and individuals be part of the like not to call the board but rather like the technical oversight committee or since Jenkins community has multiple layers and like that's why I'm hesitating not to introduce a term that is in conflict with the hierarchy of the but something like that it has oversight over this operator the community going forward that it goes in the right direction and neither us as redhead or nor Virtus.Lab or any other one can like push it back in the in the like wrong direction essentially mm-hmm yeah so just to clarify and to provide some insights yeah I've been in contact with actually both parties over past weeks though I didn't get much response on my from Virtus.Lab so far but yeah I was separating basically as individual I think that one of the ways which is quite clear and this is actually why we have a Jenkins governance board is to reach out to parties as Jenkins governance boards and to see how we can meet be a bit and whether we could find the way because for example for me one of of these proposals was to have a kind of working group etc is three parties so that none of the parties actually is dominant one of the ways is to have let's say one representative from Virtus.Lab one representative from Red Heart and another representative from the governance board or something like that but yeah it's one of the ways and personally I believe that it would be the best way to proceed actually to create a working group etc may eventually on board more parties and yeah there is a kind of incoming proposal with these details for that but the second way we discussed is actually having a second repository one or why it's important because yeah assuming that Virtus.Lab keeps evolving the existing project and there is significant deviation for example there is a roadmap proposal for May 21st it was submitted based on the discussions at the community meetings so Kubernetes operator has weekly meetings which I referenced from Jenkins calendar so basically this roadmap was discussed in these meetings and yeah current state that there is roadmap proposal basically getting no reviews etc which is a concern on its own I would say so for me one of the ways would be to actually have internal fork so when we have current operator which evolves basically how it evolves and we create another fork which becomes a new upstream basically for this roadmap or whatever use attempt to create open governance maybe and which evolves separately so yeah it might pose issues with stars etc so it's likely to be a hard fork with some period of chaos when users will have to understand what is iterated is what and the community will need to adjust but this is the second way I proposed the problem that we actually have now clearly let's say Jenkins governance maintainers of components retain soul power in Jenkins core etc we have mitigation process but for components basically maintainers have full decision and yeah I checked all the documentation unless you apply code of conduct there is no actual way to do permission transfer when a maintainer actively disagrees with it for but of course it is just the current situation so basically for me it's open governance easily and I propose to negotiate with Richard Schlapp under these other parties as first step and probably somebody else from governance board could be driving this discussion because at the moment I am rather involved and one my question was my intradity because I'm really interested about in the future of this project and yeah second way is to actually start preparing to hard fork this option to actually replace an existing fork if it's inactive like I'm more than happy to join the conversation if you need some else from governance board so regarding time zones maybe Uli has a better overlap but yeah Alex if you have been right so awesome yeah Kubernetes is nothing that I'm touched with I don't know much about Kubernetes that's a good thing just in the sense of being a completely unbiased third party hopefully okay so I guess our next step would be actually to start a formal discussion in the mailing list is all the context and Alex if you can be leading the discussion yeah I may contact you just to get a little bit of background before I send that email out but you can definitely sign that action to me yeah so yeah I guess Siamak and the third team have an action item to send a summary of the conversation and I will share my insights privately sure would you let me know where I should send is that is that to Jenkins there or what would be a public forum that we can so yeah basically we have two main channels for that so there is Jenkins governance board which is a private channel and there is also a developer mailing list which is a public venue so how our governance works basically all the discussions and decision making that happen in the public channel Jenkins governance board is rather for escalations for example for code of conduct etc then it's a governance board but for public decision making it's a developer mailing list so depending on the way you choose you can take the mailing list but yeah I think that since we are discussing them publicly on the record and this we can start from the public discussion right away unless somebody is against I think that's fine okay okay I would like to think why we'll send my insights to the board mailing list not because there is something private but yeah I will share what I have to say publicly and share some additional insights okay so for now yeah this discussion may take some time um do you seek any immediate steps are you fine with us kicking off the discussion yeah that's fine yeah yeah from my perspective that that's fine because I like this this needs to I think this needs to also set an example of going through the right process right so like rushing that would would kind of be contrary to that purpose as well so I'm fine with next next step I did find just discussed that on at public forum yeah so we can have status in couple the next governance meeting yeah ideally if you could get other people on the call I'm putting virtual up it would be ideal but yeah it's a kind of best effort but let's try to do it and yeah let's see how much feedback we will get because yeah once it's sent to the developer mailing list uh Jenkins Kubernetes operator is actually quite popular uh so we put a lot of adoption so maybe you could have most stakeholders in the discussion okay any additional comments and questions on this topic so Oleg is this a place or or maybe I should just bring it up with Shamak separately that the Kubernetes operator might be a great thing to have a synchronization session in the cloud native SIG context to help Xenob and others know how to document it in the Jenkins on Kubernetes project project it was the original plan oh it was okay the discussion about Kubernetes operator in June after Thomas did a presentation no it was me after Thomas did a presentation at the Jenkins online meetup we had a kind of discussion and we agreed that we is restarting of Jenkins cloud native SIG Kubernetes operator will be one of the founding projects and finding projects for version 2.0 but yeah we didn't move much further because it was summer break so I tried to organize meetings a few times so for example we tried to organize a meeting about Jenkins and Tipton etc but yeah it was related to Sargent I still I think that in principle we agree on that and yeah we agreed on the scope of the projects etc so yeah basically we agreed on this scope with a few amendments but yes once we are ready let's do that and we had a discussion about Helen charts already because Helen charts in the in the list as well and since they being moved to the Jenkins organization officially now yeah I guess it will be one of the first meetings and according to the developer amenities Mark will be hosting that so yeah I believe that cloud native SIG should actually be revived so after I returned back I will definitely be spending more time than I was able to dedicate but yeah whatever cloud activities we have 10 people who can host meetings etc so as a current SIG leader basically a blanket approval to anyone who wants to host the meeting for any topic related to cloud native SIG please do that okay thanks yeah I'm actually looking for the Helen chart thread somewhere here right I don't remember if it was there or in the doc SIG but that's okay we can add it separately no it's actually yes there it is you're right that isn't yes okay so yeah let's just keep pushing that and yeah assuming that we start reviving governance etc cloud native SIG could be additional venue to facilitate feedback because what we discussed with Thomas before there is a lot of cross dependencies between Jenkins and operator for example how to efficiently use jcask how to efficiently use new features maybe how to integrate Jenkins file runner into the scope so there is a lot of opportunities we could discuss and yeah let's just try to do that more contributors we have it's a good opportunity for us okay so we are going cover time even more than expected so any other topics to discuss before we close the meeting okay yeah one topic is the next meeting so it's September 9th in principle I should be available in practice I have no idea what will be my network quality so it would be great if somebody else host this meeting I was curious there Oleg isn't isn't the two weeks after September 9 likely to collide with DevOps world so should we would we benefit by saying we'll instead shift the next meeting out one more week and meet the the 16th of September so that we avoid then avoid and avoid DevOps world which is the following week it would make sense in principle so again assuming that we do time sensitive discussions in the developer reminder please and do not wait for the meeting then yeah basically the meeting is just a status check for everything so I am fine we're moving to September 16th and Uli is the other board member present are you okay with that it's okay it's a good idea we clarified this is only once and not a new schedule a good question so if it's well I'm I was assuming that September 16 and then two weeks after September 16 yeah that wouldn't work because I mean we would detach the meeting dates with the LTS from the LTS schedule ah that's a danger okay so moving to September 16 is fine but your point is it's better if we get back on cadence so then my my proposal may not make any sense okay so what we can do September 9th and then September 16th then because September 9th the release date does make sense that makes sense yes and yeah in the worst case so yeah basically again governance meeting doesn't necessarily have to be hosted by the governance board member so Uli if you're not available if Alex is not available yeah maybe Mark or Daniel could host it okay yes September 9th is great then thanks then September 16th and then not TBD but yeah I agree that it makes sense to skip the week of DevOps world because many participants have commitments there then make more sense to move the September 16th and one week after the DevOps world I think that we can just have a meeting after that so it would be October something yeah then back to common schedule right great yeah so keeps us on the cadence so we aren't we are missing the LPS dates good thanks for that insight Daniel again yeah we can it means that we will meet one extra time but at the same time we can just keep our meetings let's say 30 minutes not like today let's see okay does it work for everyone okay then let's assume that that's the plan and yeah for roadmap review I think we can target September 16 then or 9 whatever works yeah I would prefer 16 I don't think that it's it's urgent that we do it and it's great if it's in in your voice and yeah okay thanks for reminding me that I still need to look what might talk about it okay so yeah I'll move it to the next meeting okay no other topics for today right so thanks to everyone thanks Samak for joining yeah the talk about which is the recording this feel free to join the next meetings because again it's a public venue for everyone who's interested in the Jenkins project thanks for the opportunity