Jenkins Governance Meetings, 26 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jenkins Governance Board Meeting, Aug 26, 2020

Description

Regular Jenkins Governance meeting. We discussed changes in fork relationship for repositories hosted in the Jenkins GitHub organization, incoming Governance and Officer elections in 2020, incoming community events like GSoD or Hacktoberfest, and open governance proposal for Jenkins Kubernetes Operator.

Full agenda and meeting notes: https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.cgd8zbewht8o

A

B

C

Recording is started.

B

Thank you, hi. Everyone welcome to the jinx governance board meeting today is august 26th and uh we will have a discussion of several topics, so we have six contributors on the call um and yeah uh based on our agenda. We will talk about some news. Then we have a github relationship proposal from danielle jira upgrade discussion, also preparation to uh the next important officer elections.

B

uh I think up on the incoming community events, a roadmap review, which we tentatively added to this meeting, to follow the jab 14 process. But again it depends on how much time we have and kubernetes related governance discussion. uh If we get time, let's discuss that and yeah, I guess that's all topics we have on the list.

B

So does anybody have any news to share.

D

This was brought up in this week's infra meeting, but I think we can mention it here as well. um We are now serving our jenkins core and plugin downloads via https.

D

um 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 even problems like uh corporate proxies, rejecting any outgoing http, urls and stuff like that, are no longer a problem. So basically it's modernizing.

B

Camera infrastructure right so.

D

We solved both infra 160 from 2010, as well as infra 266, which is not a lot newer.

B

Okay, so yeah, there are all the issues, then one which is referenced from the roadmap. Excellent, because I want to discuss infrastructure roadmap.

B

We took quite an abstract um topic because it includes not on the dissolving mirror beats, but yeah big thanks for doing that and the daniel. If you could update this epic and tickets today would be awesome uh but yeah. I guess our next step would be here, would be to actually have more mirrors, because before we were blocked due to lack of each person mirrors now, we can actually reestablish the mirror infrastructure.

D

Additionally, we also probably solve the problem of downloads not being available for the first hour or so after a plugin is released, so that caused some problems, especially with new jenkins installations. Whenever uh new releases were released of popular plugins right now, this costs, some more money tim will know the details there, um but for now it is resolved until the bill comes to. I guess.

C

And- and I am delighted to have proven what daniel described I downloaded a plug-in that had been released, 51 minutes prior and no issue thanks daniel marvelous.

B

Result uh great and yeah thanks a lot uh to daniel to tim for working on that it's pure infrastructure, but it should help our users a lot and combine this package. You can say your stabilization, some fast dvd, hopefully downloads will be much more stable.

B

Okay, other news is here: we had a security release, so it was a few days after the previous meeting evening is not able to mention that daniel.

D

Nothing really notable there. What might be more notable is the one we had published just five days later problem there was that the jetty, integrated, servlet server.

D

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 out, basically as as quickly as we manage as as quickly as possible, the weekly releases were not affected.

D

As I said, we did a routine update there. um It was only lts. I think it went overall fairly. Well, um since we went from from identifying the problem to the release in two two days to two week days,.

B

Yeah thanks a lot to that in another issue, change which we integrated is also open. Images update, which was was a kind of one covered here, but yeah thanks to alex mark and other contributors for handling that, because now our alpine images officially run on adopt open gtk with the recent versions of alpine linux.

B

So it should be much more convenient for users. I guess our next steps to actually update uh all other images stored on top and gdp.

A

B

I think you have a problem.

A

For that uh already, but I'm.

B

Not sure whatever yeah there was a request: yeah, you use packaging structure, changes, etc.

B

Okay and another thing which was mentioning right now we have a vegas branch for bug, porting for the next lcs baseline, all right yeah, this it gets to this thread, so the branch is ready. We are slightly behind the release candidate, but yeah. I guess we could get it out tomorrow.

B

So and then we will go on track right.

B

So but yeah the branch itself should be ready. uh There are some discussions about, for example, gluten framework, purchase, etc, but.

B

I think that overall, it should be stable enough in the current state.

B

Okay, so any other news to.

B

B

I guess no and let's go to github for relationship manual.

D

As I proposed a few days ago, a few weeks ago um on the dev list that we uh clean up the folk relationships of repositories in the jenkins ci github organization, we have a lot of folks in the organization, because that is how the hosting process works.

D

um Someone creates a repository in their own account and to host it in the jenkins project. We create a fork using the github api.

D

um 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 palm and so on and so forth. um And so my proposal is to clean this up.

D

I've confirmed with github support that, if both the jenkins ci organization owners and the owner of the upstream repository agree, the fault 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 determine 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.

D

Where there is a list of all of the forks in the jenkins ci organization- and my proposal is to reach out to the folks 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.

D

um 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, um I expect that that is the 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.

D

All of the feedback that I received on the developers list was universally positive and are no even brought up how he experienced problems because of dysphoric relationship, because it's confusing and automated tools do not handle it really. Well.

B

Isn't built for plugging duplicated but yeah anyway, it's off topic, yeah, it's deprecated uh yeah uh one question I had uh so we are talking about all the repositories, not specifically plugin repositories, right.

D

um Mostly plugin 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 um structurally.

B

And this involves 30 percent of our repositories right, so it's 810. each.

B

D

Damn I 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 um and I will just skip any repository where there would be problems that would result in something akin to data loss yeah. So.

B

It would be great. uh 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 whether 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.

E

um I don't want to impose at all so I'm also listener. But if I get a vote I I obviously would use that yeah. You get a vote. Everybody.

B

Gets a vote? um Yes, so alexa. What do you think? I'm a plus one.

A

I would like to investigate if we can change the hosting process so that we.

E

A

Do this in the future, we've had discussions in the past of trying to do transfers repositories instead of working. So I think it'd be good if we reviewed that, so we don't have to continue.

D

So that's that's one option. Another option would be um 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 that. This is, for example, what the jenkins security demon does for the private repositories that we have.

D

We just create a new repo and mirror everything from the public repo, and then we work on security fixes um that should the result should be the same, uh except in the case where it's an existing.

D

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 this looks. 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 report transfer. Perhaps I'm not sure how easy that is to automate um for the minority of cases uh where we want to retain stuff like existing issue, trackers and pull requests.

B

uh Well, it doesn't have to be manual because github supports transfer requests. Now it's not that 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.

A

Oh really, the the well. It means.

E

We could initiate.

A

The we can initiate the transfer, I guess via the bot, in our current hosting process,.

C

A

Then they would just have to approve it.

D

D

A quick question, the repository transfers: can we request an inbound transfer, or can we only or do does the uh person requesting the hosting do they have to request a transfer from them into jenkins, ci.

B

From what I remember the later one, but yeah github changes quite quickly so might be. The second option is already available. Sorry, the first one, but.

F

We want the first one, I think.

D

The second one looks the second one seems to be a bit cumbersome, so I'm not sure how pre-practical that will be in practice, but we can. We can keep that in mind.

A

Okay, I'll go take a look at the apis and see what's available now.

D

So I mentioned this in the thread on the dev list. I see these topics actually as 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 ask people in hosting requests to. Please uh delete their repositories, um which would end up, hopefully making the repository in the jenkins ci organization, the canonical repository um from which they can fork again. So um in that sense, we never for a long time.

D

We didn't actually want this relationship and we've recognized that it's a problem, um it's just that the tooling hasn't caught up, and I don't see a reason why um one would necessarily block the other here. So I can go ahead with the default relationship cleanup of existing repositories.

D

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.

B

Relationships, I agree with that and yep we can uh review it separately. I created an action item for you alex so say: mark. What's your opinion, I.

E

I'm also plus one for it uh on one side uh from ownership perspective. I think all the communities I'm involved in follow the same, that the ownership of all those repos need to be with the uh with the main project jenkins in this case and having jenkins fork, uh another repo or vendor repo thing. That kind of goes the opposite direction and the second one is uh to an like outside looker, uh especially for smaller projects.

E

The direction of contribution becomes misleading when the repo is somewhere else and is forked into jkci and there they should get involved in where things happen first and then propagate to the forks. um For anyone that is deeply involved in the project that won't be misleading. They would, they would know exactly how this works, but uh if you, if you're, not you're, not deeply familiar with that uh just getting involved, it's not that obvious that all of the work happens on their janky, ci, repos and then chair.

E

They get cherry-picked by the repo that was actually originally forked right, so definitely for it.

B

Okay, so I guess we're in agreement to move it forward.

B

Okay, anything else uh on this topic.

B

Okay, moving on jira update uh fun, progress mark.

C

So the plan has been discussed with linux foundation. I have a number of action items. um I've got to get on those action items, uh they're related to getting a backup getting ssl access, etc.

C

This plan is accessible publicly. So if you've got comments on it, you are welcome to make those comments. uh The hard stop deadline is november 28th and we'll continue working on it.

B

Just to make sure we continue with migration uh without changing identity management right.

C

That is correct, that was a 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.

B

Great one less service to maintain it could be better, okay, anything else on this topic or except action item for everyone who is interested to take a look at the plan.

G

You need to read the plan first.

B

Oh okay, okay, we don't vote on anything specifically right now, so yeah, it's just status, update right. Okay, then, if no other comments moving on.

B

Okay, 2020 bought an officer election, so I started the discussion uh yesterday in the mailing list, so this discussion basically submit in advance because, assuming that we follow one year, election interval officers, we expected to hold an election in november so that the results are effective in early december.

B

But still there are some topics to discuss because well obviously the elections is a bit complicated and secondly, 2019 election uh was quite complicated from the implementation standpoint. So there are some discussions how it was done. There is also public retrospective we had for the previous election yeah. Basically, this is what we created in december. I guess 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.

B

It's completely feedback to three groups uh voting registration process uh this last year. It was quite difficult because we needed to send emails to 100 solvent accounts, also to get their consent. There'll be a lot of concerns about eligibility, etc and then, generally in gbt, we have issues from two sides. Firstly, we had no way to verify various uh technical accounts and generic accounts yeah. We know that uh there are accounts owned by teams. We know that there are test accounts like 15 accounts or 4 dva, and something like that to provide an example.

B

At the same time, we had a question actually with whether our voting is inclusive enough, because we will relying on jenkins ldap database, but um currently you don't have to be in the database to contribute. You can just use github github issues. You have to request, you can write a blog post, whatever answers stack, overflow, money fees etc, and you won't be eligible unless you create a hold up account for the election. So this main concerns, and also basically a lot of manual stuff.

B

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 functional eligibility, verification so what it means we send emails. uh Basically, two mailing keys uh supposed in social media, etc, and anyone uh can sign up. Then we do verification uh based on providing data.

B

So we will ask users to provide github accounts, jira ldap accounts, and if none of it works reference to a public proof of contribution, and if one of this waste is confirmed, then a voter is considered to be eligible.

B

Obviously, then, two major pain points is, firstly, how we automate verification, assuming that there will be hundreds of voters like last year um and how we do manual checks, because uh last year we avoided manual checks just by providing an escape hatch if you're not in.

B

If you didn't get notification, please send us a message: nobody really did, but this year it will be more likely with public announcement and public sign up, but there will be more users uh submitting requests and putting public links to something like the including profiles who knows um 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. uh This is just up for discussion and yeah.

B

You can see that there is a bunch of comments flowing but yeah if somebody has experience with public voting systems and sign up. If there are some tweaks, how we could uh automatic eligibility check, please feel free to comment.

A

Yeah well, like I had one question: when would you propose starting the google form to collect those who would like to vote in election.

B

So assuming we hold the vote in november, we should start to sign up in october. It doesn't have to be october 1st, but definitely it should be that few weeks to sign up.

B

Yeah, this is something we can define so again. I just started the document to kick off the discussion uh if we take 2019 process, so I'm just going back to some time to direction implementation well, especially in the mailing list, partially on the website, but here was timing proposed by tracy yeah retrospectively. We know that this timing didn't work because we had issues again with sign up fees, we're sending all these accounts with create configuring grid properly with collecting this data.

B

But here so we had lamination phase and yeah. Here we don't really have a voltage signup at all, because it was a kind of uh basically strong implementation uh during.

B

The voting, so I'm just trying to find it but actually sign up, was uh just uh implemented uh uh right on the flight and uh I'm not sure how much time did we get to something like two weeks. I guess that point.

A

I'm just I'm just worried that, um with the amount of verifications we may need to.

A

A

Weeks before and then time to do the verifications and uh without any verification issues.

F

With actual voting.

B

Okay, so basically alex what you say that two weeks might not be enough for sign up and for verification as well right.

B

We can just set some ballparks, for example, if you say that sign up time four weeks well, four weeks might be a bit different. It's possible and yeah also voting time.

B

So, for example, if we say four weeks here, then let's say two weeks here and two weeks: verification.

B

um It means that we would need to start on october, 1st to hit the timeline.

D

Why do you want? Why do you want to serialize sign up and verification.

B

Yeah we can uh somewhat paralyze it.

B

Still, we will need.

F

B

Okay, so one week or so.

B

B

B

A

B

So yeah, I basically reduced the verification time to one week to address daniel's comment. Is it uh what you were talking about because I didn't quite get.

F

B

B

Breaks: okay, so what I suggest to do.

B

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 dive. 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.

B

This is also one of the retrospective feedbacks, because.

B

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 step-by-step guide with all these phrases listed and this assumption that we can deliver on this time frame, I think it would be there to go so for now. I propose to keep discussing this google doc, and then somebody will need to move it into a single selection process, documentation.

B

Now, for that there is obvious reason that yeah what I communicated to developer managers- they will be basically off until september september, sorry september, 17th or so um so.

B

If we start working on that at this time, would we fit? Would we hit the timeline or should we continue working on that in the next.

B

B

Kind of read comments but yeah. I think let's just uh continue in the developer, one at least because my god feeling 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 some grid process like before, we have a bit more freedom but yeah again, I'm not 100 sure about that.

B

B

Talking, let's uncover the next governance about meeting.

B

B

But yeah any feedback will be appreciated.

B

Anything else on elections, or should we move on because yeah with alex in the car, I'm not sure we can discuss efficiently right now: okay, incoming community events and programs. So just quick update uh what to keep in mind.

B

So google season of dogs, 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 uh bernat, separator and other bits again. This scope is a bit abstract right now, because one of the parts is actually define a final plan and the mentors will be working on that together with mankind.

B

But if you're interested, please join the world season of docs channels, because here the project topic is set- and I guess the agencies on kubernetes is quite important from the community video standpoint.

B

So hopefully we will be able to use this opportunity well, because what you get is just an experienced technical writer uh contributing to the project uh for four months, including planning and yeah. Let's try to get quest of that and yeah thanks to mentors and to all candidates, hopefully because yeah this year we had, I guess, 10, plus candidates. Applying uh 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.

B

That's why I have community bridge for dogs 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 drive this topic because it actually boils down to two questions. Firstly, budgeting and secondary mentors, because we have no problems with mentees.

B

Thanks to google season of dogs, 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, at least to mentor project, and also we ideally need a kind of stipend and right now, as we know, we are quite low on the budgets.

B

We have started funding proof of concept, but we haven't started, pushing it to fund raise money, so unless we find a corporate sponsor right now, 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 somewhere in the community, please contact us because this, how we get the projects running.

B

Budgets yeah: we can shake some trees.

B

Okay, so yeah, but yeah main concern about that that, even if you run it, it will be next.

F

B

I don't think that we can feasibly start the project uh in the next months, taking all other requirements.

B

Okay oktoberfest: this is something we cannot start uh 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 oktoberfest 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, junk score features.

B

Well, I would say that, uh overall, it was quite a good experience for the organization and we should keep doing that at the same time.

B

The question is about format, because last year we tried to organize local meetups as a part of hawk for breakfast, how to breakfast organizes local meetups as well. Obviously, this is no go option, so we either need to do something crucial like we did in previous year. We had a kickoff sessions like this local events yeah. So we had a grand opening session where we had presentations about how to contribute.

B

We also had hot cover, fest results. So this, I guess it's a kind of minimum format, but yeah we could probably at uh more meetings online meetups, contributor and tabs in the middle, for example. Similarly to how we did uiux hackfest in may, so here we had how many meetups 10 or so yeah. This is uh what we published here, and actually we had more ad hoc once so it really depends on how many, when white we have and how many maintainers join the initiative, because this local events depend on richard projects.

B

So this is the list we had in 2019. So there are still some topics we could move on so, for example, jinx warnings, ngo plugin. I guess we would be interested to document something I'm not sure. What was the experience for you? Would you last year, do you get contributions.

G

G

Just some newbie contributions, but I think it was only five or so, and these were mostly my students, so.

B

G

Maybe this is not the best topic.

B

Yeah for configuration of code, we definitely got contributions. We got contributions for jenkins for our jinx 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 terminology cleanup, because we have this project documented uh on the documentation seek 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.

C

The the docs office hours has been adding systematically going through and doing triage jonathan morris and vlad silverman have both been working. Those kind of topics, so I think I think we've got good potential for at least dockside many opportunities that are well vetted by the time we reach october 1.

B

Okay, so online meetups featured projects and yeah also we need organizers. So does anyone want to be in the oktoberfest working group this year.

A

B

Okay and yeah, I think we can send a message to the mailing list, so we could get some usual suspects joining so hopefully you will get some by the way.

C

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.

B

Okay, now, let's see okay, so I think that I will send a message to the developer of melanchris to start coordinating that.

C

Oh, like you want me to take that, given how loaded you are, I can. You can certainly delegate it to me and a big chunk of them will be docs.

B

Thank you, yeah yeah. I will uh still do my best to help but yeah, taking my availability in general and thanks a lot.

B

Okay, um so um yeah moving cone, devops, vault yeah, quick update, alice, is looking for volunteers because again we will be doing kind of jenkins stand devops world this time. Devops fault is virtual, so you don't have to go anywhere. At the same time, yeah we still need to mend the booths, etc and yeah. All contributors are welcome and pretty much the same for cdcon. So for cdcon the format is yet to be decided. So devops vault is september.

B

22Nd 24th. If I recall correctly, this is october, 8th, 9th but yeah for cdcon, jacqueline salinas and cdf. They are looking out for jenkins representatives yeah. If you interest, please join unboxing outreach.

B

Meetings yeah, so I guess it summarizes all community events. We have uh I'm not sure whether it really makes sense to even touch a lot more preview, because we had quite a number of topics today. So maybe we could kick it down the road, especially since the roadmap is pretty much up to date. We reviewed it in the middle of july.

B

Is it fine with everyone?

B

Okay, so I will add it here: okay,.

B

So samak, would you be interested to talk about kubernetes, separated governance.

E

uh Yeah, absolutely: is it one hour to call so like 10 minutes.

B

We can go slightly over time, but people might start dropping, uh but yeah.

E

I'll adjust to the like time. I have uh little details, so the background is that we as a red hat, we have a number of engineers, a team that works on the kubernetes operator for jenkins. The great hat is an advocate for operators on kubernetes in general, and since we have a lot of customers that run jenkins on openshift, we we want them to use the kubernetes operator. Instead of just deploying the images say, they get much better experience with configuration of jenkins and backup and all those capabilities.

E

So we got involved in it about a year ago and the initial work was done uh by virtuslab.

E

They had done a great job as bootstrapping this as a part of the consulting efforts that I think they had done uh with that reverse project setup. That was discussed that the the repo is active at virtuous lab is forked on on jenkins, and we have tried over the last year to like to collaborate or we have been collaborating with richard's lab. I think the problem they have recently had throughout the the time is that uh there is a non-existing path to to a commentary status on the on the projects.

E

The virtuous lab 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 visual slab has of the operator and their customers, um which is understandable but like, but it's not healthy for um for for for the operator itself. So the way we have we are in a similar situation as red hatted very of the projects that we are involved in open source project.

E

We are invested in the success of the project and then we drive within that community things that our customers care about, uh 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 same. These are good and uh and that that's how it will help the community would work when it's a single vendor, then it becomes a a place for the interest of a single vendor as well.

E

So a lot of the prs uh there are numerous like more than 10p are the thing that they've got rejected so far, and the rest of them takes months to to get to get marriage because of the the pushbacks of not being in line with what virtuous lab customers want, um and they have been living this reality for about a year. What recently has happened is that virtual slab does not have their. They don't want to spend much time on the operator anymore.

E

They don't have the resources. The main committee 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 uh until he came back he's feeling better coming back, but the recent communications that we have had and I'll ask my team to send the email again with the longer background to the to the public.

E

uh Mainly 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, uh which is fine. This is obviously every every company has a different priority. So this is uh nothing unusual there. What is unusual is that they they want to keep uh the sole ownership of that project, which that that's the issue real that uh that you they don't.

E

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 going to 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.

E

For it we get a lot of good feedback about the operator, both on kubernetes and openshift, so we are invested in we're, hoping that more vendors get involved, more individuals get involved, and this becomes the thriving component of the jenkins community.

E

But the current situation seems that this is not going.

E

Unfortunately, in that, in that direction, and- and we have tried to converse with virtuous lab for uh a number of times to address this, because we you, like the communities formed through the members of the community- does it shouldn't need to be like intervention from outside to to fix that, but, unfortunately, that didn't give any results either.

E

So this has been our last resource to reach out to oleg and and raise this are concerning the situation to to the board, see if there are any paths to uh to get more more people involved, uh we we don't want to red hat end up in that situation, either so kubernetes opera. In that situation, I mean to be the sole owner of this repo right.

E

We we want the kubernetes operator to to have, uh through the community guarantee this arrival of the operator, regardless of if there is a red hat tomorrow or ritual's lab tomorrow or not so that that's really what we want from that community.

E

um So the ask is basically, we have had a couple of chats with oleg as well. The ask is to see how we can.

E

What are the path is to turn the kubernetes operator for jenkins into a more like a multi-interest or multiple sides, and vendors and individuals be part of the um like not to call the board, but rather like the technical uh oversight committee or uh since, since jenkins community has multiple layers. I I'm 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.

E

It has oversight over uh this operator, the community going forward that it goes in the right direction and uh neither us as red hat or no virtuous lab or any other one can like push it back into in the like wrong direction. Essentially,.

B

Yeah so just uh to clear, refine and provide some more insights. Yeah I've been uncovering contact with actually both parties. Over past weeks, though, I didn't get much response on my uh from my virtual up so far, but yeah I was separating basically as individual.

B

I think that one of the ways which is quite clear- and this is actually why we have junkies governance board- is to reach out to parties as jenkins the governance course and to see how we can mitigate it and whether we could find the way because, for example, for me, one of obvious proposals was to have a kind of working group etc with three parties, uh so that none of the parties actually is dominant.

B

uh One of the ways is to have- let's say one representative from virtuslav one represented another representative from the governance board, or something like that, uh 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.

B

There is a kind of incoming proposal these details, for that second way, we discussed is actually having a second uh requisitory uh one or why it's important, because again, assuming that first lap keeps evolving the existing project and there is significant deviation and, for example, there is a roadmap proposal for may 21st.

B

um It was submitted based on the discussions at the community meetings, so bernardo separator has weekly meetings, uh which I referenced from jake's 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.

B

I would say uh so for me, one of the ways would be to actually have uh internal fork, so when we have current operator, which involves basically how it rolls and we create another fork which becomes a new upstream basically for this roadmap- for whatever this attempt to create open governance, uh maybe and a visible, separate, so gate might cause issues with stars, etc. So it's likely to be a hard fork with some a period of cows when users will have to understand what is operator is what and the community will need to adjust.

B

But this is the second way I proposed the problem, I that we actually have no clear way. I would say, jenkins: governance, maintainers of components, retain sole power in jenkins, core etc. We have a mitigation process, but for components. Basically, maintainers have full decision and yeah. I checked all the recommendation.

B

Unless you apply code of conduct, there is no actual way to do permission transfer when a maintainer actively disagrees with it.

B

Well for better, of course, this is just the current situation. uh So, basically, for me, it's open governance immediately and I propose to negotiate with uh and with other parties as showstep, probably somebody else from governance. Sport could be driving this discussion because at the moment, I'm rather involved- and one of my questions were my unique rarity, because I'm really interested about in the future of this project and second way is to actually start preparing to hard fork.

B

This option to actually replace the existing fork if it's inactive.

A

Oh, like I I'm more than happy to join the conversation. If you need someone else for the government.

B

So, regarding time zones me, maybe william has a better overlap, but yeah alex, if you have bandwidth so awesome,.

G

Yeah kubernetes is nothing that I'm touched with.

A

I I don't know much about kubernetes, just in the sense of uh being a completely unbiased third party. Hopefully.

B

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 uh discussion.

A

Yeah, I may um 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.

B

So yeah, I guess uh siamark and team- have an action item to send a summary of the conversation and they'll also share my insights. Privately uh sure. Would you let me.

E

Know where, where I should is, that is that to uh jenkins damn or what? What would be a public uh forum that we can see.

B

So yeah, basically, we have uh two main channels for that. So there is uh jenkins governance board, which is a private channel and the results developer manufactures which is a public venue, so how our governance works. Basically, all the discussions and decision making happen in the public channel jenkins governance workers rather for escalations, so, for example, for code of conduct etc than its governance board, but for public decision making and it's a developer man at least so, depending on the way you choose, you can take the mailing list but yeah.

B

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.

A

Yeah, I think that sounds fine.

B

B

B

So I will send my insights to the both million list, not because there is something private but yeah. I will share what I have to say public publicly and share some additional.

B

B

So uh for now yeah this discussion may take some time.

B

Do you seek any immediate steps?

B

Are you fine with us kicking off the discussion.

E

And yeah: that's fine, yeah yeah from my perspective that that's fine, because I 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. um So I'm fine with the next next step. I didn't find you just discuss that on that public forum.

B

So we can have status sync up at the next governance meeting.

B

Ideally, if you could uh get other people on the call, including kirsten, it would be ideal but yeah it's a kind of best effort. But let's try to do it.

B

B

And yeah: let's see how much feedback we will get because yeah once it's sent at the developer's militarist, uh jinx bernard separator is actually quite popular.

B

So we've got a lot of adoption, so maybe we could have more stakeholders.

B

In the discussion.

B

Okay, any additional comments and questions on this topic.

C

So like is this a place where, or maybe I should just bring it up with shawna 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.

B

It was the original plan. Oh, it was.

G

B

The discussion about kubernetes operator in june after thomas did your presentation. No, it was my after thomas. I did a presentation at the junkies online meetup. We had a kind of uh discussion and we agreed that uh with restarting of jenkins cloud native speak kubernetes separator will be one of the found new projects 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 uh a few times so, for example, youtube half.

B

We tried to organize meetings about jenkins and dipton etc, but yeah it was relatively second. I still, I think, that uh in principle we agree on that and yeah. We agreed on the scope, what would be the projects etc? So yeah? Basically, we agreed on this scope with a few amendments, but yes, once we are ready.

B

Let's do that and we had a discussion about uh helm, charts already, because health charts in there are in the list as well and since they being moved to the jnkc organization, officially now yeah, I guess it will be one of the first meetings and according to the developer managers, marquis will be hosting that.

B

So um yeah, I believe that cloud native seek should actually be revived.

B

So after I return back, I will definitely be spending more time than I was able to dedicate but yeah, whatever crowd 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 a meeting for any topic related to call native c. Please do that.

F

B

Yeah, I'm actually looking for the helm chart thread somewhere here right.

C

I don't remember if it was there or in the dark sick, but that's okay. We can add it separately. No, it's actually! Oh there. It is there. It is you're right. That is it. Yes,.

B

Okay, so yeah, let's just keep pushing that and yeah, assuming that we start surviving governance et cetera, quite nfc could be additional venue or to facilitate feedback, because what we discussed with stomach before there is a lot of cross-dependencies between jenkins and operator, for example, how to efficiently use jks how to efficiently use new features, maybe how to integrate jenkins file runner in telescope.

B

So there is a lot of opportunities we could discuss and yeah. Let's just try to do that more contributors. We have from it's a good opportunity for us.

B

Okay, so we are going over time even more than expected, so any other topics to discuss before we close the meeting.

B

Okay, yeah one topic is the next meeting, so it's september 9th uh 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 hosts this meeting.

C

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.

B

It would make sense in principle so again, assuming that we do time-sensitive discussions in the developer remaining please and do not wait for the meeting then. Basically, the meeting is just a status check for everything, so I am finally is moving to september 16th.

C

And julia is the other board member president. Are you okay with that? It's.

G

D

It's a good idea to clarify this is only once and not a new schedule.

C

uh Good question, so, if, if it's well I'm I was assuming that september 16 and then two weeks after september, 16.

D

Yeah that wouldn't work, because I mean we would um detach the meeting dates with the lts from the lts schedule.

C

ah 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,.

B

So what we can do september, 9th and then september march 16th then because september and that's the release date- doesn't 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 a governance board member. So only if you're not available, if alex is not available, maybe mark or daniel, hosted.

B

C

Yes september 9th is great, then thanks.

B

And 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.

G

It then make more sense to move the september 16th one week after the death of sword.

B

G

B

We can just have a meeting after that, so it would be a october, something uh yeah then uh back to common schedule.

C

Right great yeah so keeps us on the cadence, so we aren't. We aren't missing the lps states. Good thanks for that insight, daniel.

B

Again uh yeah we can. uh 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.

B

Okay, then, let's assume that that's the plan and yeah for roadmap preview. I think we can target september 16 then or nine whatever works.

C

Yeah, I I would prefer 16. I don't think that it's urgent, that we do it and it's great. If it's in in your voice and yeah.

B

Okay, thanks for reminding me, the testing request might talk about it: okay, so yeah I'll move it to the next meeting. Okay, no other topics for today uh right. So thanks to everyone, uh thanks siamak for joining and yeah talking about watches the recording, please feel free to join the next meetings, because again it's a public venue for everyone who is interested in the jenkins project.

B

Thanks for the opportunity.