 Hello. Hey, hey. Hi, Dan. Good. Colding, Brisbane. It is. I had to put my gloves on this morning when I went for a walk. Good morning. You're kidding, Sally. It's not that cold. It's cold. This was before 6 a.m. Everyone. Hello. Hello. This is everyone already. Maybe wait to us. So how long we know we wait? About that. Yeah. Okay. All right. Let's do that. Might be worth a quick ping in this code. To say that it's happening now. Yeah. Great idea. Okay. It's not fast. Sure. So first, some housekeeping. I'm sure everyone's seen this before, but please read that if you haven't seen it before. Note that this meeting has been recorded. And mute unless you're speaking. And you can use the raise hand or we can just use the chat feature too. And so, all right. Looks like there's no general announcements here. So no, nothing else in here, although I think it's worth calling out under the release updates that we pushed out a fix for the 23.4.0 release for the docker image. We had an issue with that where the docker image was not working on processes. So that change went out, I think yesterday to fix that issue. And that fix is also included in the, we'll be included rather in the 23.4.1. I don't know. I think there's anything else to add in the release updates. Unless anyone wanted to add to that. Does anyone know when we plan on doing the point one release? That's a good question. What is the scheduled that should be soon. We have that in the release schedule. I'm just trying to see what it is. See what's in here. It's not up to date, is it? Yeah. So, I think we might be worth a check on that date. But when was the 23.4.0 release? More than two weeks ago, three weeks ago. Yeah. Okay. So we're, we're due for the, for 23.4.1 release then. Yeah. Do you know if there's, does anyone know if there's anything blocking 23.4.1 release at the moment? I don't think there's anything blocking it. Let me just, uh, Waiting on a bottle to you. Okay. Fair enough. I thought there was something. Well, I'm sorry. Oh, the 53.30. Yeah. That's probably the one. The get account. Well, I'm just trying to find it. We got it. Kareem's get account. Yeah. That's what I'm thinking of. Right. Okay. 53. 30. Yeah. I'm just trying to find it. We got it. Kareem's get account. Yeah. That's what I'm thinking of. The 53. 30. I guess it's a question. Whether that's a block or not. I'll put it down as monthly blocking and we'll have to have, we can have more discussion. I guess. With that. If you think it's a blocking issue. Yeah. I think it was Diego that was asking about that one. Cause it missed the last release. Yeah. Let's find out what's, um, what's the point out from Kareem. We can go ahead without that or not. I'll link to that afterwards. Um, All right. Work updates. We've got nothing listed in there. Did anyone have any updates they wanted to share though? Move on then. We do have some other business listed in here. So it looks like we've got some proposals. So one of them is a, a repeat of that, that release improvement. Um, Which is this one here. So I think this had just been a discussion on the other time zone call. Um, I'm saying any comments since then, um, though. Um, So I think you were, you were the one to propose this. Have you, um, Any more feedback about this proposal? So all the feedbacks. Um, On the calls or, Uh, Which I've then addressed here. Okay. Uh, so. Yeah. Everything you've got on the screen there is basically, It's basically. So. Yeah. I mean, Speak up if anyone's got any extra points. I won't go over. Over this again. Cause we've already discussed it on this call. Um, But yeah, I'll see. I'll put it in the agenda again for the next. Call. In the other time zone and see if, um, Yeah. This same people want to have, um, Respond back to some of these comments that I've made. Um, Uh, so I'll give it one more call after this, I think, and then, And then try and figure out where to go from there. Okay. So yeah, you'll bring this up. You're going to schedule this for the next, um, Is it here? Uh, US time zone call. Yeah. So I think maybe the difference, but I've rewritten the proposal slightly. Um, Okay. Since the last time we discussed it on this call. Which is basically to. Put a bit more focus on the main thrust of this, which is avoiding cherry picked releases. Um, Um, Um, Um, Um, Um, Um, I think last time it was about. Replacing the current schedule with the monthly schedule, but that was really just. One possibility we don't have to do monthly schedule. Um, Yeah. It's really about avoiding the time sink of, and the complexity of having to do cherry picked releases and keeping main, Uh, The main branch releaseable as best we can. and keeping the main branch releasable as best we can. So that's, yeah, trying to focus on that point a bit more. But yeah, please, if you've got any feedback or comments, discuss them now or put them on that page or in Discord. Okay. And what about Max's point here? Will this still allow for us to create feature branches? And do patch releases occasionally or is this putting a strict policy in that? Yeah, definitely, like not trying to create any strict rules or anything is we should be pragmatic about it. I guess the main point is that, you know, we might have to change how we test things in order to keep main releasable. But if we're in a situation where we're not confident with what's on main for whatever reason, and we need to do a hot fix, then I don't see a problem creating a release branch ad hoc. Like I presume there's nothing stopping us using the previous release is get tag and creating a new branch off that. And kind of doing it by default. You know, just do it ad hoc as needed. That would be my suggestion there. Okay. It doesn't look where any of the people who may need the suggestions are far back on here. So let's just say anyone else who wanted to talk about this now. So thinking through like the changes that we would have to make to the way that we do things right now, like feature toggles, we kind of did that already. But I guess it's sort of making a bit more prominent in our process. But is that the main change to the way that we work at the moment? Apart from the release itself? Yeah, well, I guess people, different people were working different ways. So some people might already be working in a way that's compatible with this. For example, like completely testing everything before it gets merging to main and being happy with the level of testing. Rather than kind of relying on the burning process to test stuff, which it might be there. Everyone's doing that already. I don't know. No, I think I agree with you that it might be a little bit different for different people. Yeah. The feature type of thing, I think what if we treat that more as a normal working practice in Basu. I think what that unlocks is the, like people being comfortable releasing a partial feature that doesn't necessarily work, but is still production quality code. And, you know, committing to main more frequently and therefore having smaller PRs and not being in a situation where we've got a huge feature that is really hard to review and then adds risk and we need to do like a breaking change, not breaking change, but like, you know, we need to de-risk it by doing a quarterly release, etc., or delaying it until the quarterly release. So just want me to guess that a little bit. But yeah, I don't think I'm seeing too many cases where we've had a feature toggle that is kind of bit used to develop a feature piece by piece. Most things tend to be kind of big round features. It might be a change there. I don't think it really changes things that much. We already have this assumption that we're releasing off main for the two-weekly releases anyway. So I think it might change the riskier changes that we might be delaying for the quarterly release. We might have to think more carefully about how we do those now. Yeah, I think it's probably day-to-day stuff, but there's no change. It's just these big ones. And the big ones, feature toggles work for some things, but if you're making changes to an existing feature, that's not always so easy to feature toggle. We'll have to think through what that actually means. Yeah, I think potentially in some cases it adds some overheads. Either because you might spike out a feature and then kind of break it up into smaller PRs, which obviously adds a bit of overhead, but maybe is actually more efficient compared to us doing a long review process. And yeah, I think I had another point, but I've forgotten it. So let's carry on. Yeah. The other point was you're saying around the... So yeah, so the downside is it might add some overheads potentially. In certain cases it's more effort to either breaking up a PR or testing more upfront. The benefit is that it keeps main releasable and then smaller PRs and stuff like that. We get faster integration onto main, basically, and keep the release process becomes easier because you can trust what's on the tip of the main. I guess I always had this assumption that we will go for main-based development anyway, but we never had anything formal saying that either because we do do releases off the main for the two-weekly releases. So I thought that was always my assumption. I don't know, I guess we have different understandings of what it was. So it's... Well, but I mean, best case scenario, maybe everyone agrees, oh yeah, main is already releasable, in which case this becomes like... So challenging why we need the quarterly process for risky changes if we are happy with what's on main already? Well, I think that's a separate... That looks like it's a separate from your proposal here, the quarterly releases. Is it or is it part of this one to address the quarterly releases? If main is always releasable, I don't think we need quarterly releases. Yeah, I think there's more discussion. I think there's no reasons for that for people. I think that we... There's changes around deprecation and testing strategies, but yeah, I agree. That's something we should definitely discuss. Yeah, I think the deprecation policy can work in either situation. I don't think we need a quarterly release branch series of... In order to do the deprecation, we can still do it without... I think you're right, we can find a way to do that, because we'll just have to come with a strategy. Was there any other thoughts on this? Well, we're here on the call. All right, move on. It's like, yeah, you've been busy. You've got another proposal there, Simon, for log in improvements. Did you want to... This looks like this is the first time this has been down from on the call, so did you want to talk through this one? It's been something I've been thinking about for a while, and the meaning to do a PR for some related... Like a PR to improve some of the logging, but I thought it was a good opportunity on this call to maybe try and discuss some of the issues and get some feedback on it first. But yeah, essentially, I think it would be nice to be able to use the default logging debug level and get some useful debug output that even end users could navigate. I wouldn't expect them to navigate everything, but at least they'd have a chance of maybe spotting something themselves, and at the very least, it would be an easier conversation when trying to debug with them for them to copy and paste some things into the screen. Currently, the only way to really get some decent debug logs from a user is to instruct them to target certain packages, Java packages, so you have to do quite a... You basically have to write the RPC for them that will change their log levels on certain packages to get anything useful, really, which also involves them probably adding the admin endpoint RPC category as well. So it's a bit of a faff to debug things by logs at the moment, but also improving the developer experience of debugging, because I think there's a lot of logs that are in debug that probably should be in trace. So the two big things I'm thinking of that is peering logs. There's a lot of information on that, and there's also, I think with the Engine API, if you put debug on that, you get all the RLP. So that can often take up the whole screen, for example, or more than one screen, and that makes it hard to work with as well. So yeah, this proposes that we would limit what's in debug to something that's a bit more readable, a bit closer to one line and a whole page of text, and remove anything with lots of raw data in to trace level. The easiest way to do that would be just to remove all these problem... Move all these problematic logs to trace, but we could probably spend a bit more time on it and make it a bit nicer. For example, there are certain logs that might be useful, but you maybe only need a bit of the information, like the block hashes or a list of block hashes, for example, and then put the full request or whatever into trace instead. So you'd have a debug version and a trace version of the same log. So those are things we could do with it. But yeah, I think it would be useful to discuss, maybe especially the peering logs on this call, I think. Probably Sally and Stefan have, and maybe Gabriel have some thoughts about the peering logs if you've been working on peering for a while. There's definitely a lot of output in the peering, and yeah, maybe we should have a ticket and look it over and see what's really necessary. Yeah, it'd be nice to know what should be at info, debug, and trace. I think their levels are a bit over the place. You shouldn't have to go to debug for everything either, and when you do go to big agree, there's an overload of information. Yeah, and thanks for doing this proposal, Simon. I think it's a time to remind that. And I do think it would be good to take a holistic look at all the peering logs, and yeah, as you just said, Jason, figure out what should be at info, debug, et cetera. And same with the transactional pool, if that sort of has similar issues, it would be good to take a holistic look at the transactional pool logs rather than looking at the logs, I think. Yeah, I think that'd be really good. I'd like the approach you've taken here of what work you need to solve the common problems. I think that's a good way of looking at it. Like, if you've got a peering problem, what information would you want at info, debug, et cetera, to kind of start diagnosing any issues or seeing this a problem? That's a good way to go. One thing is, we could look at other clients, too, and get inspiration for what they do. I remember Tech, who actually spits their logs, if I remember correctly, into the main log and then log file, that has more detail towards what some people would always go back to that if they need to. I think we even had a ticket at one point to do something similar in Basu to have the console versus the log file logs, like Tech, who does. But I think we sort of decided that it wasn't high enough priority at the time to do it. So the ticket might have got closed rather than like this. I'm not sure. But I think that's another difference to this. Yeah. You know, I quite like that approach as well. I think it does add some complication to the operation of it. And it would be a first, I guess, everyone that's already set up Basu. I don't know if it'd be a breaking change or not, but you'd probably have to set some things up. But it's a common question for people to not be able to find their logs. I think a lot of people use system D. And I'm not sure exactly how much that keeps of the logs, but it's not the easiest thing for users to get ahold of logs when they're using system D in the way that, when they've followed the staking guides. So having a file there might be a lot handier as well, rather than kind of everything going to console all the time. I wonder if we need more levels too, because we've got info, debug, trace. I think it goes to five levels, if I remember correctly. Yeah, you can have a fine in certain libraries, can't you? I'm not sure we need to do that with a login library. I'm not sure. I don't need to go there yet. But I've considered the same thing. I think there's definitely certain things that could go into fine instead. But I think if we do a, you know, concentrate on getting a good debug level, we could just pretty much dump everything in trace. And then I think once you're in trace, you probably need to be targeting things anyway. I think that's probably a really good first step if we get info and debug usable. Like I said, if you don't trace, you're expecting a lot of information. The less logs, the better. Like the higher signal, the better. We should look at it all. But a quick route to something useful, I think, is to shift a load of stuff into trace. Yeah, I guess we're probably just not feeling this to the least look at what's in appearing at the moment, whether it all makes sense to be a debug or not. Thanks, Sally. I'll put that in there. Nice. Yeah, the old one. Nice. I'm not committed. He's a snack, but it could be. And so did someone say they were going to look at the peering logs? I'm quite happy to. I'm kind of deep into basic logs at the moment for the mistaking case. Yeah, use case. Okay, I'll just put down that we identified peering as being one of the causes of a large number of the logs and debug. As a quick win, maybe I'd be happy to open a PR to basically move all the peering logs from debug to trace if people think that's a useful thing to do. Sorry. Sorry. So I think you're probably right. A lot of them can go to trace. I think everything that is like an error or something could stay in debug because that shouldn't happen too often. But other information is probably right. It should move into trace. That's a good point about the errors. Yeah, we have quite a few things that are like errors, but they go into debug because they're not like some errors or whatever. Yeah, we'd have to be a bit careful with that. Yeah, I think I'm at the idea here kind of getting rid of the spammy ones because we do get some common logs over and over the debug level that are filling out the logs. Yeah, to be fair, we probably don't have to remove too many to reduce this spam quite a lot. But yeah, since I'm analysing the logs at the moment, maybe I'll open a PR to try and get some quick wins. Just as an initial step in this, but it'd be good to discuss this on the next country piece call as well in the other time zone because we did too much with it. Yeah, it sounds like there's no objections to the general idea there. Love it. No, I think it's a great idea to clean up the logs. Things to find to review your PR. Thanks, Deborah. No worries. The only other thing I was, yeah sorry, lost my train of thought. Oh no, I think it's a really good, doesn't put any other thoughts in there, and of course, my thought that I had on that. Was there anything else that anyone wanted to talk about? We don't have anything listed here on the agenda, so open forum. That's fine. Oh, I see something. I'm going to check here. Awesome. Why Ted just posted something about Tamil bars, I thought that would be worth bringing up. Okay, that's interesting. Yeah, it's going to raise that. I guess as a first point on this, I just want to tell what people think. We've talked about moving base to Tamil bars in the past, like a Tamil config instead. Is there any reason we couldn't do that? Or maybe I've only heard it in certain contexts rather than the whole. I don't know whether that's something that is desirable in all cases for base or not, but I thought it was worth bringing that up from the off before we maybe go down the road of changing some Tamil stuff. Yeah, that's a really good point, Simon. I don't know what the downsides would be of going to Tamil. Take a user's Tamil, right? It does. Yeah, it definitely does. I mean, the downside obviously is the breaking change. Everyone had to change their config. Oh, I guess we could have capability. Yeah, it's nice to work with. It's a lot of Tamil, but I don't think you're going to get unnecessary a lot of advantages from moving to Yarmul. Why not both? Let's just make it. Yeah. Yeah, which is maybe where we'd end up if we added Yarmul. We're using some of the other products too. Yarmul's a little bit cleaner than Tamil and you can do this configuration you can't express in Tamil easily that you can in Yarmul, but we're also not taking advantage of that in basic right now. I guess if we had a simple convert, if we could convert people's Tamil configs to Yarmul, like we might have to support both for a while, but eventually we could convert to Yarmul. Yeah. What was the advantage of using those tables? There was a table sections in Tamil. It was not something we'd have to use and we don't use them. It's found what we're doing right now, but it might be beneficial for some libraries. I think that was the argument that trait Yarmul, Tamil files. Yeah, but I think it's also that basic just won't read Tamil code if they have those tables in them, but it doesn't ignore them. It just fails. Okay. So yeah, so I guess, yeah, it's to be changed. We could either change the Tamil, the way that it reads the Tamil files to make this better, the tables better, or we could say, well, move to Yarmul if you want this extra bunch of answers maybe, but I don't know if Yarmul would support this, the tooling in a different way, in the same way, sorry. It might be, yeah, I might respond to Matthew in Discord to just ask about the idea of Yarmul support, but do we think what Matthew's proposing would be a breaking change at all? Possibly. Could we keep comparability with table or non-table Tamil files? I guess we might be able to have like a default table or something. I'm not sure how that works in Tamil. Yeah, I don't think it would be a breaking change. I think it would be just to say, when we're parsing the Tamil, if we come across a table, just ignore it. Oh, is that most of the issues, just not to break those tools, not to actually use them? Yeah, yeah, I think so. Okay, sounds like a reasonable thing to do. That seems reasonable then. I thought it was actually to start using say, P2P table label, whatever it's called, and everyone's changed to use that, but if it's just ignoring them, it should be fine. Well, I think that would be the sentence to get rid of this. Local table, I don't know what they're calling. I think so much, which you could just start opening up PR then, at least create a ticket for them. It's not going to have any downside. Yeah, well, Simon, are you going to respond to Matthew's? Because he said, the reason I haven't opened an issue yet is, blah, blah, blah, I have this question. So if we can answer this question, then I'm going to give you the answer. Yeah, what was the actual, it was just looking for the back that was the natural question. Well, I think he's sort of saying that Basu isn't doing anything wrong right now, because everything we read in is flat. We don't need to use the tables. Yeah, so I think from this call, it sounds like there's no objections to ignoring the tables. Would that mean that we're actually reading it in Val though? Or could we actually go to the table section when we're not using it? Well, he also brings up the point that we just would document that we ignore the tables. I think that's the way over here. Yeah, we could do that. Yeah, that sounds like a reasonable play. Okay, so you're going to respond back to Matthew on this one, Simon? Yeah, I'll do that. Okay, great. Thank you. Anything else? Anyone want to discuss that? That sounds like everything. Then I'm going to stop sharing this. Thank you, everyone. Thank you.