 Hey, hi Peter. Can you hear me? Can you hear me now? Is it better? Hey, yeah. I can hear you now. Are you seeing something? I can't hear you now. Can you hear me? Yeah, yeah. I can. I can hear you now. But I guess now you're on mute. So no one else is going to join? No Peter, I think you are on mute. It shows you are on mute. Can you hear me? Can you hear me now? Yeah, I can hear you now. Can you hear me? I cannot hear you. I can hear you something. Okay. Peter, can you hear any of us? Hey, can you hear me? Can you say something? Yeah, I can hear you. Oh, I can hear you now too. I don't know what that was. Okay. Are we waiting for anyone else? Do you know if Ram is coming or have you, have you heard of from? Rama might join later so we can start. He said. Okay. Welcome everyone to the Hyperledger Cacti Maintainers meeting. Please abide by the antitrust policy. That we have that I'm showing on the screen. And also by the Hyperledger Code of Conducts, which you can find linked to you on the agenda document. And then the first item for me. Is that I propose that we move the meeting an hour and a half later, because I've started to get conflicts with the 8 p.m. time, my time. So if you open this link that is in the agenda document that I also just put on the chat. You can see what that would look like in different time zones. And then I'll update the calendar invite for next week. And then we can discuss if it works for everyone or not. Second one, CI performance. Jack Preet is not here, but I know that he's made some headway with running only specific packages that are, that have either source code change or a dependency of them had source code change so that we can only, we can run only the tests for the typescript packages that are actually necessary. In a way that is guaranteed to not cause issues where we miss a bug just because some tests that was affected did not get executed. Another thing is that Rai gave us some numbers on how much the CI is costing on the paid plan where they put us for the increased performance and it was insane. It was like $150 per pull request on average, which is completely unacceptable high cost. So I just told him to put us back on the free plan and then be fast tracked that pull request that made this happen because otherwise the foundation of it have gotten charged thousands of dollars more potentially by the time we get the change through the usual review process. And then the other thing that I was looking into but not done with it yet unfortunately is the mono repo publishing for the go packages. I created a sort of a playground for that. And my personal GitHub account, I forgot what the name of it was, give me one second. It was something, yeah go mono repo test. Yeah, so this is what it looks like. I have some tags here, which are just releasing, you know, the ABC packages with certain tags. And I haven't gotten to a point yet where it actually works that they will get released at the same time. But it would I was going through the forums and what people are doing to make this happen. And then they claim that it's possible, you have to just do the go mode tidy after setting the version to a specific commit. And you could, in theory, this whole theory, you could put that commit hash into the dependency declaration before you actually merge that exact commit to the main branch. And the thing we need for this is just to guarantee that the commit that you cut the release with locally on your machine is the same commit hash that will end up on the main branch. So in theory, if we can do that, then it will just work, quote unquote. If the hash is match, and this is what I found on the internet, but I want to actually have a working proof of concept with this test repo before I suggest that we actually do that in the official repository for cacti. Because if there's any sort of side effect with it that I just didn't clean from the forum post that I was reading, then I want to figure that out here instead of just making a big mess out of the release process for cacti. And yeah, I'll put a link to chat about this as well. And what else? Oh yeah, so this is all I had. These are my updates. So about this, you're saying that if you make the dependency as a commit hash in the go module, but that commit will be the one commit before the release commit, right? Because we'll have to make that change in the release commit. Oh, no way that may not work. Because you would need. Yeah, but the moment you modify the dependency declaration with the commit hash, you will have to amend your commit. But then you will have to. Yeah, the only way still possible, but you will have to alter some of the commit attributes that go into the commit hash. So, for example, if you amend, if you did a commit amend that way, then the commit hash would change again because the commit hash includes the time stamp of when you're committing. And so the way to do that then is to amend also the commit time, which would mean in the end. I'm commit. Yeah, so you have to manually do something like this. Instead of letting it default to whatever is the current time stamp. I think that way you can make this magic happen when you have a commit that has its own hash in its own diff referencing itself. And if you push that to your branch, then it actually is supposed to work in the sense that go should just be able to look at it and say, Oh, this is the commit hash I want. Is that on the remote? It is so cool. Then I'm downloading it. This is all very like one more thing. The commit needs to be on the main for this to work. So you need to amend the commit on the main. They said it does not have to be on the main. It could be on the release branch. Allegedly. Okay, they wrote on the forum. Okay, the release branch would have to be on the official repo. But that is already how we do it. If you look at the branches, we have branches for the releases. And these branches do get pushed before the pull request itself of the release. Because this is actually what we cut the release from. Okay. So there's a lot of ifs here. I know that basically there's so many conditions and exotic it features and whatever else. You know, there's an 80% chance that this just won't work. But I want, I do want to try because. If you could make it work. Yeah. And then if it doesn't, at least we can document why it doesn't work and then we just go with some more complicated process where the release is not a single pull request, but it's just a bunch of pull requests where you basically you need a pull request for each go module. Right. That's like the plan B. Yeah. Yeah. So I'm trying to avoid that because I think that's just bad because then we cannot point at a single commit saying that is the XYZ release. And it just becomes a little confusing. And it's more complicated because I have a bunch of pull requests to send you to slowing down the CI. Yeah. So hopefully this thing that they claim works will actually work. If not, then there's what it is. Okay. Yeah, that's all I had. Anyone else with any other discussion topics? Nothing from my side. Okay. Then thanks everyone for joining and I'll talk to you next time. Okay. Yeah. Thanks. Bye bye. Bye. Bye.