 Hey Izzy. Hello everyone. It looks like everyone's here. Hello. She must ring and let's get started. No one's either okay? Hopefully it's not too small. Yep. Great. Okay. Let's go through the housekeeping first then. So, any trust notice there? If you go to this link here you can read the details. You would have heard the announcement already that this is going to be recorded. So, if you don't want to record it, then you can turn your video off. Yeah, please mute if you, unless you're speaking and if you have a question use the raised hands. Although being small we can probably just, small group here. We can probably just answer on the fly. Okay. Let's start off with some general announcements. I don't see anything listed there. Does anyone have any general announcements they want to make? I'll take that as a note. So, moving past that. We're doing the roadmap listed here. I don't think there's anything new added to the roadmap. Since we looked at it last time. No. So, this is Shanghai upgrade. I think it was last time we hit in the 23rd. Actually, there's been a recent modification. I can't see what it is. But currently we're focused, we'll be focused on the Shanghai upgrade. I don't think there's anything else to talk about in the roadmap right now. There's probably some, in terms of Shanghai. There's been some detail thing added here to the next upgrade though. I don't think there's anything to base it to the Cancun upgrade. Is there anything anyone want to discuss on the roadmap? But we're going to come to the rest of the call. Make sure this is the right one. So, we've got the release rotations. See that in the Contributor channel, there's been a post date for March 8th for the next release. This also has the date for the post date there. So, what were people's thoughts on the next release dates? So, this last one was a bit later than we had hoped. So, I think this one moves it back to a Wednesday. I think we did strictly two weeks from this. I think this was a Friday that wouldn't have worked with a typical schedule. So, that's why I believe that was moved. I think Simon, you raised this. Did you get a sense if there was a consensus on March 8th being the release date? Everything I've heard so far has been a favour of it. I haven't heard anyone object to it. Okay. Well, that sounds promising. Yeah. Okay. So, as far as we know so far, the next one will be March 8th. And then from onwards, we'll plan to continue doing the two-week releases for the point releases in the 23.1 series. So, that's the case. Yeah, I think we basically got to more or less the end of this week to make a call, because we have to start burning in at the end of this week. Yeah. I guess it's probably too late to be any sooner than March 8th. Yeah. And I think that one of the key things we wanted in that, ideally, would be the Gaulie Shanghai configuration, if it's available. Yes, I do. And Lisa's just saying we should have the Gaulie slot decided this week on the All Four Devs call. So, that should work out nicely. So, we should know in the next few days when Gaulie should happen, and we'll have enough time to include that in the next release. Yeah. I think it probably depends on how Sepolio goes, but it's a success for rollout. We should be able to define Gaulie in a minute. Next. Yeah. Yeah. So, fingers crossed, Sepolio works as well. We'll find out in a few hours. Now, segue that. The Shanghai Epic. So, I might just open this epic up. I think you're probably the person to talk to this, so I'm not going to see your face there on there. Did you want to give a quick update on the, how we're going with the Shanghai withdrawals? Sure. Yeah, I'll keep it brief, but feel free to ask any questions. Basically, all the kind of main bits of the code are done. The things that are still in progress and still to do are related to adding in more tests and improving the robustness of, well, our test code, because there's quite a few different frameworks involved. And yeah, we obviously, as mentioned on track for this, Sepolio release in three hours. And yeah, if there's no issues with that, should go smoothly with the Goli one as well. There's minimal work to do, just configurations to add in for that. And then hopefully onto mainnet. So hopefully by the time we're on mainnet, we'll have had all of these items in the Epic complete and we'll have all regression tests in place and we'll be in a good place. But alongside this, there's also DevNet's running as well as the test nets, the public test nets. So we should be pretty confident, I think, if we don't see any problems in that. All right, that sounds good. So we'll just put it in there. So ready for, and we've put an item here for work update on the improtocol deposits by an external contributor. Does anyone have any details on? Yeah, I put that one in there as well. I wanted to bring this up because it's an external contributor to the base, which is good. It's actually, I found out they have come in through the Ethereum protocol fellowship, I believe. Which is like a kind of mentorship program. And Mikhail is leading this project. Doing the improtocol deposits, this EIP is part of. There's another change to do with the execution API as well. That counts part to this. And yeah, so Mikhail is driving that and he's also the mentor for this contributor that has opened up PR and Basu. So we're just working through, but it's good that they, I think the mentee was given a choice and chose Basu to like effectively prototype this EIP on, which is really good news, I think. Yeah, it's exciting to see Basu used as a reference implementation for this or early work on this EIP. Anyway, so. Also the change itself is really good because it means we can get rid of the beacon chain having to like do stuff with the deposit logs and just makes everything work a lot nicer and lock some features in Basu like post-merge checkpoints in as well for validators. Yeah, definitely. I'm not sure there's much to add to this is probably bring more awareness, but you did have one question here was any reason not to include this on main using the experimental experiment EIP's time so feature toggle. So I guess that's it. I'm not sure if we'll necessarily be able to answer it here, but do you want to explain what you were asking there? So. Yeah, so. Dano introduced recently, I guess driven by some of the EOF changes. Two new forks that are like internal kind of feature toggle forks. There's a future EIP's time and an experimental EIP's time future is intended to be. An upcoming fork, but I guess hasn't got a name yet. So anything that we know is in Cancun can go in Cancun, but anything to the next one would be future. And this experimental one, I guess, is things that haven't been agreed to go into a fork yet, but we still might want an implementation, but this reason, for example, prototyping. So yeah, it's the first time, I think, including anything in this experimental EIP's time fork. So. It was worth bringing up and seeing if it was appropriate. And yeah, if anyone had objections to this particular EIP going in there, because it is quite early days for this EIP. It's not going to go in Cancun apparently. Right. Okay, so we're going to have it for six months or more probably. Yes. Yeah. Okay. Do you have any thoughts on that? Maybe this is the kind of discussion we need to have on the contributors. I'm going to go through a few more people's thoughts on that. It seems like we could use the experimental EIPs. I think that's exactly what it was intended for. But okay, so no one's going. So we'll see, maybe we'll just bring to the water. But we've still got time to win the most that PR in so we can get them. Okay, I have the discussion on the. And I can shoot it as a. Discord. See if anyone has any thoughts on that. And if anyone is up for reviewing this PR as well, the contributor was welcoming some early reviews, even though it's in draft. Right. Yeah. So it's going to see someone doing some, some of these, some of these EIPs for us. Okay. That's it as far as work updates. We've got a few items here in the other business. I think this is your item here. I'm selling on the most. I think it did you want to. What this is about and. Yeah. Yeah. So this is a feature in GitHub that is currently in beta. I have tested it out in some. Two other like test repositories. We haven't tested them basically yet, but it looks cool. It looks easy to use. It's essentially the same as enabling auto merge, like if another PR gets merged in the meantime, and you would normally need to merge from main again, it just handles that for you. So it essentially manages any PRs with whether you've hit the button to add it to the queue. It manages it as a queue. The only real change to how we currently work is that if you want to. So when you set up merge queue, you choose squash commit sounds like the strategy to merge. And how we work now is when you hit the auto merge button, you get to edit the commits at that point. So the change would be that if you wanted to squash the commits and edit the message, you would need to do that manually on your PR. Before you add it to the merge queue. So that's kind of really the only change to the way that we work right now. So my question is, can we turn it on? Can we try it out? Do we, like, we probably don't want to enable it in the middle of doing a release, you know, just in case there are side effects, but maybe after the release, maybe before the release. Any objections, any concerns, any questions? So just, once this features on everyone, this will be the only way to merge. Will they use the merge queue? Yes, correct. So if you, so when you set it up, it's not called enable the merge queue. It's called do you want PRs to, like, do you require a merge queue? So it just means that, yeah, even if there's only one PR being merged, it will just be managed as a queue. Yeah, I don't have any objections to it. I think it's, could help us. Maybe less so in our time zone. I haven't had too much of an impact upon to re-merge, but certainly at times it happens. It looks like Simon just voiced his approval of that. And I see a thumbs up from Stefan. That sums up and so far as well. That's good. Awesome. I'm going to any objections. Like I said, I think that the timing would be, we don't want to do it just before release. That would be the only thing. We want to make sure. Oh, thanks, good idea. Did you, and you haven't heard any objections in this call at all? No, the only questions around the squash commits, but it just would mean that you would want to do that manually. In advance. There was a related question. I think related. You think you said that you could actually get it to default the message in the squash commit to the description. Entitled. Yes. Yes. So that's another option when you set it up is that. When your squashing commits, you can. So the default, which is what we have right now is. It just appends all of the commit messages together. Another option is. You have the PI description. And I think the son, like the author's name. And that's it. So you could set that up, but then you'll, you'll lose everything in the commit messages. Right. So. Okay. I'm not hearing any objections to that. I think we should. I think you have to go ahead to. Put that. Yeah. So maybe tentatively we say. After this next release. Yeah. And maybe we just need to write up a little. A blurb on. The merge commit piece. And. How that works. Yeah. And if we don't like it, I guess it's easy enough to turn that off. Yeah, absolutely. It's still bigger. So there might be. Problems. Okay. And I think the other piece we want to think about, which has come up before is we commonly get. Merge conflicts in the changelog. So I think if we, you know, have a sensible ordering in the changelog, so that we're not always, you know, adding to the last line. That should sort of. Eliminate a lot of conflicts as well. I think that has become. You know, you know, you know, you know, you know, you know, you know, you know, some conflicts as well. I think that has become better, but wait and see, I guess we. Thanks. You can try it out first, because no, you can do that. That's fine. All right. that sounds good. Shore Kelvin. it's a final call to remove the base who knows this core channel. So yeah, I think we did discuss this before actually. I think this was Simon that brought this up previously. Yes, I hear you've got, you've both even got the notes here. Thank you. So on December, so that's a few months ago. So we've had some discussion. Simon, would you be able to, I guess, I don't know where the discussion's got to with the base who knows this core channel? Sure. The discussion was it was kind of old. So I'm kind of bringing it up again, really. But I think I think there was only one objection from Dano. Not an objection as such, but more clarification of why I think he created the two separate channels or requested them to be created originally, which was after the merge. We were getting a lot of support questions and I think he wanted to feel like distinguished between things that were like supporting how to run a node versus questions about base to itself, like basic features and things like that. I don't think like in my experience, people use the base who channel and the base who knows channel interchangeably. There was a suggestion to change it to base who supports instead, which is probably more clear than basic nodes, but I still think users would just use both of them. I think they have the same intent, really. It's just that they happen to be quite a bit of noise before. And that's mostly gone away now. So I would, yeah, I would still favor removing basic nodes and just using basic maybe we can split it out again. If there's a problem in the future, but I will, since Dunno gave maybe something of an objection before I will think him specifically on this floor to check that he's OK. So OK, I'll just put that in there. So there's been no other objections to removing it from what you were saying. No, no, no, it's certainly the objections. There would, yeah, there would obviously be a small deprecation window would be appropriate, I think. Or at least just making sure that all of the questions have been answered or moved over to the other channel before we actually get rid of it. OK, so that's brought up an interesting point. So that there's been much less users of usage of the base in those channels as well. So, yeah, I can't find the link right now. I can dig it up, but it's basically the insights in the discord server. And yeah, at the channel level, they still had, like, I don't know, four or five, ten times the traffic by numbers of messages compared to basic nodes. Which I think supports a view that it was useful initially, but less so now. So, yeah, I think you're right there. And if I'm summarizing this correctly, it seems that there's no objections than the plan would be to give some notice and then deprecate to remove that channel. Yeah, so I'm happy to kind of go in that. OK, great. That's not just, yeah, I think it makes sense to get rid of, like Sally said, the there's not being much usage in that people confused between between that channel, the other channel, I think, unfortunately. But I think we need both either of them. It's in the volume. Yeah, I think that's probably all the same on that one. Just so you're going to follow up on that. Simon with with with Dono and yeah. Yeah, OK, great. Now, that'd be good to go down with another channel. Is there anything else anyone wants to discuss? OK, I don't think that is a no, it's kind of like this, yeah. And is there anything we want to add to the next call? But we don't get a chance to discuss this time, I guess. We might probably think of that later. Which case I will stop sharing the screen now. Looks like that's it for the contributors film. Thank you, everyone. Thank you, Jason. Thank you. Thanks, Jason. Thank you. Thanks. See you. Yeah.