 Can you share the notes if possible? You should see them now. Do you see the notes? No, we see your file explorer. Oh, I shared the wrong window. That didn't help anything. OK, stop share. Share screen. Is that better? Yep, definitely. And if you even want, yeah, that's good. So welcome for this new Jenkins Infrastructure meeting. So the first thing to mention before we start, tomorrow we will have a stable release. So please do not modify the release at CI environments until the stable release is over. That's the first thing. The second one, so the first thing that I want to mention here, I had a look to the cost of the Azure account. And we are above the limits for two months now. So two months ago, we were close to $12,000. And this time, we are close to $11,000. So we are decreasing again. But we have to identify ways to go back below $10,000. One thing that I noticed is the network cost increased from since November to now increased from $200 to $1,600. So it's a major increase. It's probably because we've redirected a lot of traffic for the Mirrors on the communities cluster, which is something that we fixed last week. So it's still too early to identify a trend. But we still need to identify other services where we could reduce the cost. Anyway, so this is something that we have to work on. But yeah, the Linux Foundation did not complain. And overall, I think if we just look at the cost over the past year, we are still below our limits. But yeah, it shouldn't be. We should pay attention to that. Any questions? So the terms of the. Go ahead, Gareth. All right. I was just going to, in terms of the bandwidth cost, is that what's the split compared to sort of egress and egress on that? So we don't have. I don't easily have that information because the view that I was looking at is on the Azure accounts, so not inside the communities cluster. So we can definitely have some. We can definitely identify trends inside the cluster by looking at the graph and a dashboard because there we have metrics for the different services. I mean, we have a lot of metrics inside. Yeah, we should be able to tell from. There's your dashboards to a network level, whether it the cost is coming from. Yeah, bandwidth going in or out. So normally splits. It normally splits the metric into two things. OK, OK, I didn't see. I didn't find that information. So maybe I should just spend more time there. Thanks for the suggestion. So and Gareth, the reason to ask is it inbound or outbound is is that there are different techniques we use then to to reduce those costs inbound versus outbound? Or so, yeah, I'm wondering whether it's because if we're doing things like increase number of Docker belts, are we pulling more images from external sources inside? And are we paying for that? So is there some caching or relocation of stuff? Or is it down to some configuration in the cluster somewhere, which means that things I've been downloaded from it more frequently? Not sure what that would be, but it could point to somewhere in some some other misconfiguration that we've had in the past. So basically, this could give us some insight about which service we have to look at. So if it's a mirror, if it's a CI environment, if it's whatever it is. So yeah. Do it step by step. First step is separating ingress egress. Then see how you can have it on the graph now. Then next step could be per name space. Or per code, or per service, the Azure. But do it by tiny iterations just to be sure we don't start something that we don't finish until weeks. Definitely. But yeah, the most important thing is for now the Azure account is paid. The next foundation did not complain. And so yeah, we still have to improve the current situation. Anyway. So the next topic. So I propose that we discuss it immediately. Danielle, let's talk about having a new wiki in the Jenkins Infra project. Do you want to elaborate a little bit? OK. Danielle is not available. So I propose that we continue. Sorry, I was stepping away for a moment because I didn't expect the topic to already be mine. So yeah. I just wanted to bring up a suggestion. We used to use the wiki for a lot of meeting nodes and other collaborative document editing stuff in the past when it worked. And then we had trouble operating the wiki and problems with spammers and all of that and abandoned that. And since then, we started using Google Docs or, as you're sharing right now, HackMD or even GitHub gists or GitHub wikis or weirdly some stuff in normal GitHub repost that would probably, at least from my point of view, be better off in a wiki for collaborative editing. And so I wanted to bring up the suggestion to have a new wiki that is explicitly not for housing technical documentation, which should be on the site or in plug-in repos and such. But where we would put notes for the info meeting and notes for the governance meeting and that sort of content. And before I emailed a dev list suggesting, hey, this is what we should do, I wanted to bring it up to this group, whether this is something we can even support. OK, so to be honest, then it would mean that we would have to deploy a new wiki service. And in the past, we had issues to find people who weren't trusted to maintain that service. And we just end up having a snowflakes. So that's why we started using managed service like Google Docs. I'm not a big fan of Google Docs, to be honest, because you need to have a Google account to use it, which, I mean, not everybody has one. To me, the ICAND seems a good compromise, because then once the meeting is over, you publish notes on the kit repository and then the collaboration can happen there. I put a link to a pull request that I opened on the Jenkins Infra documentation kit repository, where we explain the difference between synchronous and asynchronous communication. I'm just sharing ideas. I'm not totally against having a wiki, especially if we have a smaller group of people. Yeah, I could look at if we can find something easy to put in place and easy to maintain. So pardon my ignorance here. Is there a wiki solution where we can collaborate in real time? Accepted confluence, I don't know. I don't think so. I mean, I have maybe then. Just confluence something we could get from the Linux Foundation, like they do Tira. So this is definitely an option as well. Linux Foundation could provide a managed confluence. And it will be even, and it will be so. And there we have two options. Either we transfer the current confluence data to that location, like we did for Tira, or we just start from scratch. If the plan is to use confluence again, we'll just look with them if we can just move the data from the current wiki to that new. So yeah, I don't know if the other have any opinion about using confluence again for the meeting notes. So, Daniel, could you elaborate a little further on the challenges? So is your worry that we would be better, are you thinking we would be better served by having things centralized, sort of organized for these, for notes and things like it, even accepting that we're going to limit the number of people we allow to have right permission to these things? If I can just answer your question before Daniel, my understanding and my frustration is that we know, since a while, we rely a lot on Google documents and that's really difficult to find all the information because each time we have a contributor submit, we have meeting notes, we have whatever, we rely on Google Doc and yeah, that's just awful. I mean, I'm not a big fan of Google Doc and that's why I started using Acme because then I can push the notes in GitHub. But I totally understand that Acme is not convenient for everybody. So I'm not totally against having a wiki in place again. I'm just more concerned about maintaining it. So if the links foundation is open to maintain it, I don't have strong objection. So yeah, it's similar for me. So for one thing, it's the practical problems of having a sprawling mess of individual documents that are created and abandoned. Like I've seen at companies that do something similar, we're searching and finding tends to be a mess and you don't never update anything that was created in the past and you just create a new document and you wonder a year later which is the one with the truth. And obviously wikis can also become a mess but it seems that we've handled that fairly okay in the past. And then there is also a principle behind it that I don't think as the Jenkins project, we should rely heavily on third parties, free services that we just happen to use without some kind of sponsorship because those services can go away or they can change in a manner that is not great for us. And then we have trouble even getting our data out of them again. I don't feel strongly about technology that we should be using but if I understood Olivier correctly, Confluence is basically the one that allows collaborative editing, especially real-time editing and that would be very useful to have. Obviously Confluence has a few anti-patterns like page comments which I've never seen as useful anywhere. And whenever I looked at its API in the past, I couldn't figure out how to automatically manage groups to derive permissions from, which is something I always wanted to do but the API didn't allow it because we know we have a complete list of plugin maintainer user accounts. For example, if we were to back it with LDAP and then we just do a second list with people who aren't plugin maintainers but still involved in the community and suddenly we won't have spam if we limit editing to these folks. So I think if we can get something like that done which I would be happy to look into, that would be good. So yeah, just some random thoughts. I think we should have a wiki for our collaborative editing needs and it should be something that we quote unquote own in the sense that we could have some amount of control over the data in it rather than some other hosted services. I mean, do you have any opinion Damian or Garrett on this? I think that's a discussion that should happen on the main list to have more feedback. On my side, I despise confluence for me. I waste my time and this will be for me or something slowing me down to take notes. Quite honestly, I can't. I've lost so much time trying to just save or trying to understand how to use it basically. So maybe it's just that I'm dumb. Last year we used a self-hosted instance of Etherpad which has the advantage of filling the boxes that you just listed. We master our own data. It's stored on a file system. So we just have to back up with a target. It's quite easy service. It provides real time. The only thing is what I like on ICMD and that could be something to search or so as a box is the ability to support markdown or ask a doctor's syntaxes since we use both syntaxes or on all the technical docs. So the ability to export to these syntaxes and reuse them, it could be great as well. But this is nice to have and it must have. Yeah, I see how nice it is in the second line of this document where it switched to, I think, glatech formula mode. But yeah, Etherpad was a nice one, I'm adding it. You can also teach yourself so that that could be an intermediate. So yeah, it sounds like the next step is to send an email on the mailing list, collect IDs, and yeah, this is something that I can do tomorrow. Or maybe, Daniel, if you want to send that email. I think you're better versed in terms of the actual hosting options we have. But I just fine with me. Okay, so I can work on it. So while we are talking about, yep, sorry, Mark, you have this. Sorry, I forgot. We've got a single account that we're using and there's a webinar starting in five minutes on this account. We have to hard stop. Okay, sorry. I am happy to reconvene us on MyZoom account if everybody would be willing to just let me send you a message with MyZoom account so we can continue. No, I just propose to consult because we only have seven minutes left. So I just, so I propose that if we have a specific topic that we want to talk, we talk in the RSE, otherwise we just keep the topic for next week. Any opinion on that? Okay. Daniel, is it fine for you? Nope. Then let's stop here and yeah. Thanks very much. Sorry, I should have realized that, should have thought about that and did not. Thanks everybody. That's okay. See you later. Bye-bye.