 Hello, I'm glad I'm in the right, on the right link. Either that or we're both on the wrong one. Right, Jason. Hey, does anyone know if we expect seeing anyone from the US side, Spain? Gary's away and I think Dono can't make this time. Okay, so I think that's a no. Might just be us three. One more minute and then we can start. Ah, here we go. Hello everyone. Good morning. Seems like it might just be. Australians today so I'll get started. Slaving the screen. You should be able to see that. I can't. As you would have seen this meeting has been recorded. There's an antitrust notice. Can you see the screen now? It seems to take a long time to load then. Yeah, we can see it. There's an antitrust notice. So please have a look at that. I'm not familiar with it. Yeah, I think that's for the relevant housekeeping. Not huge amount on the agenda today. Does anyone have any general announcements? I think it looks like this was updated fairly recently. So I don't know if there's anything people want to go over. It's a little chart if you do. Yeah, I think it looks like this was updated fairly recently. I think it looks like this was updated fairly recently. The Shanghai upgrade is about to happen on the 12th of April. These things are definitely happening. About that in the release section. RPC. Announcements and agreements and much. What's going on with that? Oh, yeah. And then there's Cancun. This quarter coming up. EOF perhaps. Modularization of Bayesu. There's stuff going on with that. I'm not sure about them. Oh, that is this. I'm not sure about the rest. Actually, does anyone know anything about the rest of the room? I've got any comments generally about the room. I just just related to the modularization piece. I just put back to the agenda under work updates. There's a PR in review or metrics using dagger. If you refresh. Yeah. So I think that one's still waiting for review. So that's kind of one piece of the modularization. Yeah. I think I saw Justin had previously shared. Some notes or something in the wiki. I presume that I've been in a different contributor call because it was maybe a few weeks ago now. That's the only other sort of output I've seen so far. From this. Cool. Any other comments about the roadmap. Release updates. That's 23.1.2 released on the 23rd of March. After a few days of burning. This was quite a big one actually because it included the bonds I read back to. Which seems to be going well so far. We're getting positive feedback from various users, not just about the stability with the bonds. So performance as well. I think there was some performance announcements related to that and maybe in addition maybe. I'm not sure about that. I couldn't tell you why it might be performing better. But maybe if anyone else can please chime in. It also was the Shanghai main net release. So it's got the conflict main net. For the fork on the 12th of April. And it also fixed and above it kept cropping up. Kind of. Think so many related to bonds I so maybe the refactor help that as well but basically when you did a backwards sync. This is relevant for proof of stake networks. When you did the backwards sync you would, and you were given a hash of some. The chain that you already had and sometimes that would cause an issue. So those are good stuff. This is in this release. And then more recently. I think that's what's DB eight has been released and this includes a PR which. Karen and messy I'm worked on I believe. Which could be maybe even a two X speed improvement. Or up to a two X speed improvement I think if I remember correctly. That's really great I think the code to enable this is on main now. I'm the upgrade to rusty be eight. So it should be going in the next release. I'm not entirely sure when or what form that will take though. I think we're scared we are scheduled another release before Shanghai hits on the 12th of April. I don't know. We're also due a quarterly release. So I don't know if that's going to go into the quarterly release or not the rocks TV changes potentially risky because it's a major update. So we'd need to take that into account, but I'm sure there's any discussion will take place on discord about that. Any comments about this or anything to add is the rocks TV change just for performance. Is there any improvements that we're getting from the upgrade. Yeah, I don't know. All I know about it is that it includes. Her a minute and that sounds. That basically I can't remember what the actual changes now I used to know that. That's a definite improvement for the way that we use it, but I, yeah, so I don't know that might be other good things in that upgrade as well will help. I was going to ask. You said there's going to be another release before. My point to Pella. Yeah, like if we stick to the schedule, the would be. So is there specific things for Capella that needs to be released or is it just release timing. No, it is. It is ready to go. There's nothing that needs to be released for that. So, so I think the important thing would be any, any release we do perform should be should not compromise the fork, potentially. It might be better to do like, if we get if we want to release something, especially this rocks DB change might be better to do like an RC release of some description. So like an RC for the next quarterly release. Yeah, that probably makes sense since the quarterly ones coming up as well. Yeah. Speaking of quarterly releases. Yes. I see a proposal to do something. Since this would relate to the release, let's get to this for a sec. So yeah. So I, I suggested, I kind of played the idea on discord week or two ago, and I've written a quick proposal so that people can comment or where they feel happy on a date so please take a look at this. And that's your thoughts. But essentially, it's about replacing the quarterly and by the weekly process that we follow the moment with something closer to a monthly release. So yeah the three problems. I think it will solve make maybe this is more to this that people have as my, this is just from my point of view, and from a couple of conversations. Yeah, so there's long whenever we do the quarterly releases on a long live release branch, which caused problems with like having to cherry bit code and things like that but at the very least it creates an overhead of maintenance. Compared to like releasing from main. It seems the only advantage we really get from that is that we can delay breaking changes and give people like three months notice on that. But we could still have that notice period without it needing to be like on a separate release branch for example. So there are ways around that. It's, but three months does seem like a long time to wait for significant breaking changes for release, for example the rocks to be thing. So I think there were probably better ways we could deal with that there's probably some things where we do still want to give a long, long notice period but and there's nothing stopping us just doing announcing that and then doing it and having some releases in between and doing it. So from from the bi-weekly point of view. Again, this is this mostly my opinion, so feel free to challenge it, but two weeks seems like quite a fast release frequency for users. Obviously they don't always have to do that but good impact enterprise users maybe more so than solo status for example but if you want to do something with the top every two weeks if you just kind of want it to be running stable is potentially a burden that so it kind of feels like monthly is a nice in between. And yeah, I won't go through the whole whole document but that just gives you kind of an intro and hopefully in either discuss on discord or on comments on here. See what people think. Any comments about that. We want to discuss now. So would this mean we don't release every two weeks we go, we would go to monthly. A big breaking change we would just say this is going to be in this release that's three months away from them. Yes, in essence, the way I'm kind of seeing it is like much more flexible rather than like a predefined schedule that's like a certain date for a release. I think, if there's problems we need to fix and release then we should just do it and kind of schedule kind of thing that's kind of what we the situation we're in now anyway. Although I guess two weeks is frequent enough that you can often bundle it into the next release anyway. So I'm not saying we should only release months a month. Maybe it's two or three times a month if there's some bugs that we really need to fix. But it feels like it should be at least once a month otherwise you get, you know, it is probably good to release the software and get feedback from users and things like that some sort of regular cadence and the proposal is that monthly is good cadence for that. It's quite similar to, I think, some of the clients released as well. So in the sense that the majority of our users that probably saw those takers that they kind of maybe used to that release process as well. I don't have any data to back that up. This is very much a guidance. It's just a draft proposal. We could definitely do some some research essentially to back some of this and grab what's best for users. Is there a lot of people pulled up reporting releases at the moment. I'm just wondering if there's something else in quarter releases that we don't get with the monthly ones at the moment. Not based on every data. I think we kind of generally leave some major features to the quality ones and some users kind of delay updating to the quality ones right now. So some of it might be kind of education and actually mentioning that the set gets with the same level of testing. But I think we also kind of hold back on some features right now. Out of the bi-weekly ones. Yeah. So. So is the question whether some users don't update the RCs for example, and therefore maybe missing out on some features or delay when they get those features. So what are you saying. Yeah, partly. I'm wondering if there's more to the quarterly release that we're not. One or I'm just wondering to some people hold off and only update before the releases at the moment. I mean, yeah, so they only go for the big ones and don't do the exact point release. Exactly. I have no idea. I have no idea. But the thing is, I think. There's no. Some like, we don't really. The quarterly versus bi-weekly doesn't really tell you there's been some important features by, for example, you know, this last release 23.1.2 that was just a bi-weekly release and it had like some really crucial features in like everyone's going to have to create that to follow main net, for example. And it's also like potentially a really important bonsai. So, you know, there's no kind of signal I don't think through the release cycle that this is an important release. You know, it's not like we do a major upgrade on the version or anything like that. There's no semantic kind of information in the release cycle as far as I can tell. And I don't think, although some risky changes are put into the quarterly release. You know, we don't I don't think we actually are required to burn in and there's no advantage to burning in the release for like longer than our normal burning period for a bi-weekly one. Yeah, as far as I can tell, and I've been looking at it like the only reason for it to do a quarterly release would be to delay a feature going in to give people notice period. Now, I guess the side effect of that might be that you, if you want to write the code for that change, but you've got to wait three months to notify them, you kind of have to arrange. Maybe in a PR instead of on a release branch, which is a difference or delay when you start the work, maybe, I don't know. So there might be some, you know, impacts of the way to focus work with regards to that, which could be seen as a downside for sure. I think that's something we could work around. We often use the feature toggle approach anyway. So I think that'll, yeah, we could probably deal with that. And I think there is no quarterly releases. There'll be no comparing a more frequently released to a less frequently released. So I don't think there'll be that. I don't have not having that comparison means that I think that hopefully people will just update on the monthly release rather than skip them. Maybe they have been doing the weekly bi-weekly ones. Yeah, that would be some interesting feedback to understand if users are releasing official, sorry, are upgrading. I don't know if there's a way we can tell without just asking them. So what's the timeframe for this? Do we need to make a decision quickly before we get locked into a quarterly release or does it not matter? So it's probably a bit late for the upcoming quarterly release, which if we follow the normal pattern would start soon and we'd probably do it. And to do it released by the end of April, I think. Correct me if I'm wrong, but so maybe after that one would be a good time to start. But obviously I want to give plenty of time for feedback about the proposal as well. Yeah, I think 23.4 has to be a quarterly release as you're right, it's just during the corner. But we could, like if we went to monthly releases, we could then have 23.5, for example, could be a monthly release coming after that quarterly one. Yeah. Yeah, and we still have the advantage of not having to maintain an old series of releases if we needed to. If we were released to the quality release to our own goal or something. Yeah. Yeah, there's definitely some probably finer details to work out around what are fixes and things like that and, and then the thing down to do is come up with a deprecation policy. Because yeah, that's something we need to kind of agree on I think. Dana has given some feedback that he thinks the notification for certain changes should still be called like three months. So yeah, just like figuring out. How to understand why and how we can make that decision about certain changes. And, like, I'd like the policy to be as simple as possible, but maybe we need to like have a special case for certain things. Because I think three months is probably quite long for any breaking change but like maybe there's certain ones that where we do need to do it. But it'd be good to understand the reasoning. Yeah, like the, you know, changing the JDK version that requires a fair bit of preparation so you don't want to, you know, as a user be hit by that one out of the blue but if it's, you know, a minor change to an API that's a matter to fix it, well, maybe that doesn't require three months and, you know, time. That's a really good point. It doesn't have to be the same for every feature that could actually be that some require longer nose than others. I think that the market was three months for everything. Yeah, I think things just end up kind of. Well, I don't, I don't know. I mean, I guess, you know, like if you had a port release coming up. Like, say, for example, this rocks TV change, you know, that's only just been released so now is like the earliest we could have notified anyone. So do we go three months from now or do we is a month from now okay because that's still in the kind of RC going through the RC quarterly cycle. Is the rock TV change a breaking change or just we think there might be some risk attached. I don't know if it's breaking. I'm not sure there's nothing to say. To say is but I guess that at least falls under the risky category. But yeah, but definitely, yeah, things like dinosaurs, like APIs and things like that. Yeah, it probably makes sense that we shouldn't reduce the period that people might be used to already until unless we kind of find out that everyone is okay with it being less than that. But yeah, we'd have to do some research I think to find out. Yeah, so that there's kind of two separate things right one is, can we go with a monthly release cadence instead of the bi-weekly. And then the second one is how much lead time doing to give people for the breaking changes and we could go to monthly releases and still keep the three monthly lead time for all breaking changes and then there's a separate conversation around all of the breaking changes on the a small breaking change. So we can reduce that lead time. Yeah, exactly. Yeah, I don't, I'm not sure there is it when it's talking about like changing our own APIs and things like that. I'm not sure whether there's any vantage to producing that to less than three months really. But the main thing I'm thinking about is that, that we don't have to require something like a RocksDB upgrade or something to be three months. But I don't think that's the case at the moment. But yes, it all needs to be defined. Hopefully kept fairly light touch and simple. Any other comments about this. So I'll jump back to, oh we did talk about modularization actually didn't we. Yes. Let's skip over that. So the next APAC call in about a month is on a public holiday for Australia since I think the only people on this call in Australia we are suggesting that we cancel that one. Any objections to that. I will put that proposal in the discord channel as well. Just to make sure that we catch everyone including people in arms call. But yeah, my proposal would be that we can't work. Cool. Yeah, this one, as you may have experienced or read about there was some get have actions shenanigans started a couple of weeks ago I think we're basically I think what Roy said there was a some sort of limit in get hub but they never enforced it and then they started enforcing it so there wasn't like an announcement or anything. But we at a hyper ledger level with our account there with limited to 20 concurrent runners. And so I think that started at roughly the same time we also increased our usage of get have actions by enabling the merge queue. I'm not sure whether one one kind of sent the other over but based on the based on feedback from some of the other hyper ledger projects it sounded like it was maybe just coincidental timing. Because they were having problems as well, even after we moved some of our get have actions to our own runners separate from the hyper ledger account. So yeah, I just wanted to mention that and if you say anything we would be get have actions I think the issue is kind of still ongoing some extent. So, what's happened so far is, I think Gary set up some runners, I guess owned by consensus to get around this problem. We had think we've got at least three of them running. I don't know exactly the details of the setup whether we exclusively use those or whether we end up kind of sharing them in a pool or anything like that but I think, yeah, it. We had to turn when we had the actions all kind of getting queued up and they were taking like hours to complete because of all the other projects trying to do the same thing as well. And that effectively meant the merge queue was preventing merges because the merge queue has a limit on how long something can be in the queue so it was kicking things out the queue that had been in there like 30 minutes or something like that. So we had to disable the merge queue in order to get things through. Now that we've got those extra runners, maybe we could enable it again. I don't know the current state of the runners. I think there was some issues with permissions and things like that. Which I'm sure we could fix but I don't know whether this is a permanent solution or whether we need to kind of figure out a more permanent solution. If anyone knows any more about it, please speak up. I don't know anything more about it but do we need to know more about it like, you know, if Gary set up these runners do we need to ask Gary to just write up a quick thing about what we need to know about the runners. Yeah, we probably just need an update from Gary about what the plan is with that. And on the merge queue there was that feature request, I guess, about not running all of the actions and checks again if they've already been run and that, you know, nothing else was ahead of it in the queue. Yeah. I think we'd want that to be implemented before we turn merged in back on anything. Because otherwise I don't think it's actually saving us. Oh, you know, in the worst case scenario it's more to our credits rather than less. Yeah. Yeah, so I think you still get the game of. You can just kind of forget about it. Yeah. That's the idea anyway but then. But yes, we might just, it might just take longer overall to actually get into the main branch. But yeah the downside at the moment is you always run the actions again. Even if there's nothing else in the queue which just seems, yeah. And then the GitHub actions and the circle CI checks as well. How does it do that as well. I'm pretty sure yeah. Okay. There's some feedback on the GitHub actions. Be said, where that was, I think it was like the second most popular feature request so I'm pretty sure they'll end up doing it. The first time scale would be the. The first most popular I think was the message thing where you're able to set your message, your merge, squatch and merge message, the key, which was some functionality we lost when we had it. Okay. So this probably has links to what I just saw. Yeah, I think it's that link at the top. I think it still runs all the checks include. I just think this. Because this has everything. Any other business. I've got something for the open forum. Call out for volunteers. I guess if anyone who doesn't already do the job of facilitating this call, if anyone would like to volunteer. You can share the load around it. Deep knowledge of basic and all current work streams not required. The most important requirement is that you turn up to the call. Thank you. Thanks, Simon. Thank you. Thank you.