All Core Devs - Consensus #157

Transcript

Alex Stokes: Okay, Josh, are you helping with the stream today?

Josh Davis: Yep ready when you are.

Alex Stokes: Yeah, let's go and do it.

Josh Davis: You're alive.

Lightclient (Matt Garnett): Oh!

Alex Stokes: Okay, hey, everyone. Let me grab the agenda for the chat. So this is Acdc. 1, 57. The agenda is here is issue 1515 in the Pm. Repo. And yeah. a little bit on the lighter side today. We can touch on Petra if there's anything to follow up with. There we can turn to Fusaka. and then a discussion around reconfiguring Acd. This is a post from Tim and our approach to Glamsterdam. So let's go ahead and get started. So 1st up, Petra. Anything to say here, I guess. 1st off congrats to everyone. It seems like the fork went really? Well. it was a big one, and I know it was a lot of work from all of us. So yeah, good job, everyone.

Any other comments on Petra. I'll call it here. Trent published the Petra pages, a number of perspectives from different core contributors. Trent. Anything to say there.

Trent Van Epps: No, just yes, pretty straightforward. Thank you for everybody who submitted. And it's it's always a really interesting snapshot, a lot of work to put these together, but I think in the end it's worth it to have like a perspective on what people were thinking in in the lead up to the fork. And yeah, I I hope these are useful. 5 years from now, I think some people. you know, pushing them to respond to things like the Beacon Book are. It's it's tough around the time. But then you get to go back and look at it years later and have a better understanding of what people were thinking of what their focus was. So again, thanks for people who submitted, and if you didn't, you have the form open, and you know you just lost track of time. Just let us know if you submit and we can update the published post. But yeah, the link is in the chat. So thank you.

Alex Stokes: Cool. Thank you. And yeah, Perry says, they're doing some analysis around the blob scaling because we increased the blob count and Petra. And yeah, sounds like they want a little more time to see how things go. But yeah, super exciting. Okay. And if that's it for Petra we'll turn to Fusaka. So one thing to touch on immediately is pure dos. Devnet 7, maybe Perry or Barnabas. He's here. Either of you have updates on Devnet 7.

Parithosh Jayanthi: Yeah, I can go. So the Devnet was launched a couple of days ago. I will just ping Barnabas for an update. But last. I know it was going stable, and we are mainly working on getting Bpo. Support on every client right now. So we're mainly making the Ps. To make sure that the upstream tooling is ready for Bpo. But I don't think there's anything particular to report on. Devnet 7.

Alex Stokes: Yeah, right? And yeah, then, that brings us to the next topic, Osaka devnet 0. I'll grab this spec here just in case anybody wants it in the chat. and I believe the plan for Monday was to have for Socket 0 be at least on the steel side, be pure dos. Devnet 7 along with Bpo. so I don't know if there's any timeline yet again. Maybe, Perry, you have some information there.

Parithosh Jayanthi: Yeah, for Fussaka devnet 0. We had the deadline of 26th of May. And the idea is that it just has the MoD Xp gas cost increase from the El side pure das as well as figuring out everything required for Bpos.

Alex Stokes: Gotcha cool. So yeah, I guess if you want to catch up a bit more on that this was covered on Monday's call, and otherwise. Just have that on your radar? Terrence asked. How is everyone testing the Vpo before devnet 0? I would guess Kertosis.

Parithosh Jayanthi: Yeah, we just merged in the Bpo changes today to kurtosis. Dora had broken, but I think Pk fixed it like an hour ago, so it should be fine by now.

Alex Stokes: Okay. then, otherwise. I did want to bring up this issue of value or custody. It was something that we have in the specs, and we do want for Fusaka. It seems like, though it timelines. Maybe we're slipping a bit. I don't know if that's just because of Petra and people busy with other things. But I wondered if there were any things we should discuss now around the future any open issues or spec questions worth discussing. Okay, this might be a topic for next Monday. Okay, Dustin says they're on the issues. So we can go there. And yeah, Justin, there's no Bpo in devnet 7. So

don't need to worry about that. Okay, anything else on Fusaka for the moment. Okay? If not, then. Yeah. I guess part of the reason today's agenda is kind of light is we've had this proposal from Tim to reconfigure how Acd works. Let me just grab a link to this here. and there's quite a bit in this post. But I think one big thing it proposes is essentially moving. Acd, E and C to focus on say, fork plus one. whereas the testing call that we now have acdt would focus on the current fork. So how that would look in practice is that again, as we've kind of already started with acdt that's focused on Fusaka. So again, on the Cl side, pure dos. Bpo, all that fun stuff

that then leaves the floor for this call to focus on the future fork which would be Glamsterdam. And I think today I mainly just wanted to have a conversation around this idea this post service any feedback, if it hasn't already been surfaced around this idea. I think it's a bit too early to get into Glenstream scoping today. But I figured we could use this time to kind of discuss our approach. There were a number of ideas in Tim's proposal around, not just like making this current work. Next work split, but also thinking about how we integrate the community much more closely different forms for that and all of this. So, Tim, I don't know if you wanted to say anything else about the post.

Tim Beiko: I guess. Yeah, I don't know if people have questions like, I'm happy to give a quick overview of just practically what this would look like. I also posted like some dates in the agenda of you know, if we wanted to move with this, what you know how we would approach it. has a question like, why would Acd be joint el and cl, but acd still split? Acd being being joined makes a lot of sense, because we want every client team to send people so that if there's an issue with the current fork we could address it every week, I do think keeping a split on the El. And Cl. Side makes sense, even if it's not like a super strong split, because there's just less urgency. So if we're thinking about. Okay, what's the thing going into Glamsterdam for the Cl.

You don't necessarily need all El Devs to to participate in that, and and vice versa. So I I don't have like a strong view there. But and and I don't think we should be dogmatic. But I I yeah, I I think we should try to like, yeah, move not urgent things to the right weeks. And, Matt, I guess I'm not sure I understand 33% current fork and 66% fork plus one like there is acd every week. So it would be 50 50.

Lightclient (Matt Garnett): Okay? Right? I mean, I still think that's too much for the future. Forks like we should be focused mostly on the current fork. And when there's time like right now, in the next few weeks, there's like this bit of time between really starting to Ryan the implementations of Fusaka and thinking about what clamp scenario is going to be like. Whenever we have this paralyzed track, you end up with a situation where the people who are really implementing this stuff don't always have the same bandwidth to think about the thing that's 12 months in the future or 18 months in the future, and it's not met with the same rigor that it ends up getting met with down the line. When those people do have to implement the thing.

Tim Beiko: Yeah, I think that's that's a fair point. And I think one thing to note as well is the the we in both those sentences is maybe a bit different, like a big part of this proposal is trying to get input from a broader part of the community at the start of the fork. This will take time. And so I think I expect to have, like a different set of participants, or at least partially different set of participants in in that process. It still means we need to, you know. get to like a rigorous analysis of what we want to do. But I think there's a lot of value in having a conversation a bit upstream of, like the specific eips around. What should the focus of this work be like? Do we want Grandsterdam to focus on, you know, scaling the El or some other feature? And

is that like what we think the highest kind of priority bit is. And I think this is something we need to align with, not just like core devs on. But you know, different kind of stakeholders in the ecosystem and try to invite them on awkward devs and make a case for why? Something is important. They're not important for them. And then. yeah, once we have that, then we do need like more. Input from from quarters about, okay, what are the specific things we're gonna work on. But the like, yeah.

Lightclient (Matt Garnett): No, I mean.

Tim Beiko: Extra time, I think, gives us effectively bandwidth for that.

Lightclient (Matt Garnett): Yeah, I mean, I agree with that like idea. But I think the pretty black and white distinction between all core devs testing. And then the other calls that are now going to be dedicated to future forks only is unnecessary, because we don't need to discuss the future forks, you know, once a week, every single week. There's just not enough content to be discussing it like that. And to me it always feel felt like maybe we could do a better job and be more thoughtful about when we have those conversations and maybe program it a bit more specifically based on when the last fork happened when we're going to have this period of time where there's like a month or 2 where we really talk about, what do we want at a high level. And then, like, what are the things that we're going to do in the fork to achieve those like high level goals. And then, after that period of time. We spend a period of time just like working on the fork.

And I think there's like a lot of content for working on the fork like we've filled. you know, 2 or 3 calls a week. Sorry we feel like 2 calls a week every week for Petra, and you know. Cancun, so I don't see why we're just going to. Now get away with one call a week per for the like active fork.

Tim Beiko: Yeah, that's right. And maybe like, yeah, it shouldn't be as much like a drastic split. That's like just prioritizing. So like, I think I would like to try and have acde and see like default to. You know the fork and plus 1 first, st and then, if there are urgent things and more things. Maybe we we overflow there. yeah.

Alex Stokes: Cigar. You've had your hand up for a minute.

Ansgar Dietrichs: Yeah, just wanted to say so. I do somewhat agree with what Matt has been saying in the context of how we treat hard fox today, meaning that like kind of given that. Say, take Glam Saddam as an example. Given that just now we would have switched over the focus from Pector Fussaka to Fusaka. Glam Saddam. Now that pector is out of the way that feels early. Given that Glam Saddam, I mean, at least as far as I can tell. Looks more like it's going to be a June, July 2026 kind of fog, or at least that's maybe talking to people. The seems like a realistic type of type of time span. If we if we keep having this rhythm of like 9 months between fogs, or like 12 months even, I think

then it's just too early to immediately start talking about the next focus, as basically the 1 2 before is out of the way. There is the separate question of like more longer term roadmap conversations around what even should be started to be considered or started to be explored for for Amsterdam. But I think for that. Our core devs. I mean the name already says that's where the core devs come together. It just doesn't seem like the right venue, I think, trying to take all core devs and just add more stakeholders is just fundamentally misguided. It's just that's just not where you talk about these open-ended conversations like that's more, once you have a scope you talk about like, how much of that can we actually ship? So to me it would make sense to have this longer term roadmap conversation in a different venue.

I think we're experimenting with different venues, like more researchy approaches. There can also be more other stakeholder kind of calls. I think that makes a lot of sense. The only reason to like follow this proposed new cadence, I think, would be if we actually get serious about trying to have calls at a tighter cadence. So like, if we basically already, if we're thinking, Amsterdam will happen in February, then starting to talk about it today on all codes makes a lot of sense. But again, I think the plan only makes sense. If it comes with a shortening of timelines.

Alex Stokes: Yeah, I guess one point of feedback to that is, you know, we do have venues. Or, yeah, we could have other venues for, like very longer term roadmapping discussions. Say, on the more research end, like you're calling out. But I still do feel like we're missing other types of community inputs. And then this proposal would give us room to integrate that into Acd, and sure that could be like breakouts of like Evm devs or something like this, and then, somehow, that sent as like a, you know, delegation, or like Summary to Acd. go ahead right now, at least historically, we've lacked even the ability to like service that input.

Lightclient (Matt Garnett): But that's not really to me is related to this. Like, you know, these calls are just 4 in plus one types of calls like we could be doing that right now or in the next call where we're like more focused on surfacing community input talking about Glamsterdam. And then we go back to just we're focusing on Fussaka like we don't have to then spend every call from now until February or July to talk about Glamsterdam, or from now until like September, October, when we shift to soccer. Then we'll talk about whatever's after that like. We should just get the community members to come on and talk and like make a section of time. But I don't think that we should be dedicating the entire call. I think the most important thing is just to focus on the thing right in front of us. And if we start thinking about things that are 1218 months in front of us. Then we're gonna lose. We're going to just like lose our

lose our track of focus, or worse, we're going to focus on the wrong things. And then the people who weren't paying attention are going to start paying attention and be like, Well, why the fuck are we looking at this stuff?

Alex Stokes: Tim.

Tim Beiko: Yeah, I think another part as well that we should do better on awkward as and use these calls for is to effectively review. The breakout streams that we have going on. I I feel like this is another failure mode that we have where like people work on these breakouts for sometimes years, and they only get like fairly informal feedback, or, you know, like ad hoc feedback, when like. until they effectively propose their their thing to be included in a hard fork. So the other thing I had in in my post is that I I think awkward dev should like every fork review these different breakouts and be like, do we actually want to keep them going or not? Or change them, or something like that? Because a lot of the actual big, important work takes more than you know, 6 or 9 months to ship and and develop and it's extremely bad if

you know, the time we decide to cancel something is like after 5 years of work, when you know we're having the fork conversation. So I think this is another part where, like a lot of work already happens in parallel to awkward devs, and we should use this time to like more explicitly just evaluate like, does that still make sense? And obviously, if all core devs the the decides like, it doesn't make sense. It doesn't mean that like people are blocked from working on this thing forever. But I think it it. I think I think it helps us to like, you know, one schedule breakouts to like at least set expectations like if someone's working on the thing and awkward have said, like, you know, we have no plans to do this in the next year or 2 they can still choose to do it, but it at least sets the right expectations.

so to me like that, that's another part. So aligning on the fork, reviewing the breakouts. And yeah, there will be some stuff about the current fork that pops in that that we should discuss but I I would rather like make a bit more space and have like do those things well than to try and crime it all like we've done in the past, because clearly we've we've not been sufficiently good at that.

Alex Stokes: Yeah, I mean, I do think that's the biggest risk to this proposal, is it just evolves back into the status quo. But I do think it's worth experimenting. Youth, dreamer.

Mark Mackey: Yeah, I I mean. I think there's kind of 2 dis 2 discussions going on here. One is the restructuring of the all court data call, and the other is is sort of like not planning forks. I guess, like, right after the end of the last work and kind of squeezed in at one time, and I definitely can see the like validity of wanting to spend more time, or like spend longer discussing the scope of a fork and not have it be crammed in at 1 point in time, like when we have breathing room between 2 forks. Because there's just a lot that goes into it. And I do think, even if we don't like restructure, all core dev calls that

some kind of like recurring meeting just to have people discuss like what they think would go in the fork. And then, maybe. you know, open up whatever questions, come up and then systematically look at those questions. And just just so that we've spent time on thinking in these directions and then have a like. By the time it comes time to have the discussions about what actually goes in and and make those decisions that we've just had much more opportunity to like field those questions and and have a direction that we're headed. So like, maybe one way of doing that is rather than repurposing all core devs just having a call. That's kind of ongoing about, you know, future discussions. I mean, I'm not.

That may or may not be a a possible solution. But I'm just thinking that. yeah, when we have more time to discuss these things. I think the outcome would be better, because I think, certainly with Petra. One of the differences was that we were. We were kind of caught flat footed. You know, it was kind of the 1st time that we actually didn't have an immediately obvious priority for what the fork should be in a long time, like we we knew. You know, we had the merge. Then we had withdrawals that we had 44. Those were all, obviously the priority. And then. if if it's not obvious what the priority is, then it requires a lot more discussion and time.

and so have that kind of going on in the background. We'll have a better idea.

Alex Stokes: Right? Yeah. And I kind of see them as additive like Osgar mentioned this protocol research call, or at least he was gesturing at it. And that's like one experiment to have this like longer range conversation. I still think, you know, we could have multiple venues where we have these like longer term conversations. We'd still want to have time in Acd to like, incorporate that and decide as core devs. Tim.

Tim Beiko: Yeah, I think maybe it's helpful if I share what the actual concrete thing I'm proposing. so it's a bit less abstract. But so I wrote a follow up to this. You know, to to that 1st post. Let me see. Sorry. okay, hopefully, people can see the screen. Okay? So basically, I think the thing we should do is when we start planning a fork. I guess we 1st agree on what the big core thing should be. And this is when we should get the communities input. Like, I think a failure mode is if only core devs. Think that you know this thing is important, and the entire community thinks something else is important. We should resolve this upfront before we spend a year working on the fork.

So this should be like the 1st spot that we actually proactively reach out to the community like, what is the core thing we want to do. And why is this important? Then figure out what is like the actual eip or feature that we do for this? And I think it's important that we separate this from, like all the other eips, so that when teams are reviewing, like the core headliner feature, they can focus their attention on this. If there's competing features. They can like review them thoroughly. But, like. you know, we we 1st choose, like, are we doing the merge, or are we doing 4, 4 or or whatnot. I think the other part that's gone wrong is that we kind of expect the community to give input all of the time. And this means they give input none of the time. And they, you know, like, only find out about changes at the last minute. So I would move towards like explicitly signaling that when we're discussing this 1st fork focus, this is when we'd like their input

and then the other parts that we should do is. Historically, we've had these like community test nets that we've launched for forks and we've done one for for for Petra for 7 7 0, 2. I think we should just be clearer that, like this is the sort of last call for the community to give more kind of in the weeds feedback to propose spec change and whatnot and then, like, yeah, the other part. It says, like, you know, we should, we should formalize these working groups and review them. But I think at a high level these 3 things is what I would propose practically changing. So we we reorient the conversation around like, what do we want to do? The community comes in. Then we choose our headliner. Then we, you know, we pick all the other eips once that's done.

And then, once we have a a core feature implemented, we set up the public test net. We get people to look to look at, to it to propose spec changes, and then we assume that once that's done like people are kind of happy. And then yeah, I I think then, if you look at like Glamsterdam specifically. I posted this on the agenda. Let me just pull it up real quick. Glamsterdam. Specifically, it means we could spend, you know, the next month or so discussing with the high level focus for the fork should be whether it should be the same on the El or cl, or separate bring in, you know, different perspectives from the community. We ideally agree to this by say, you know, early July, and then everyone kind of knows this is the big thing that's going to Glamsterdam. We can. We can keep working on Fussaka. If we have extra spare cycles, we can start working on this core feature, and then we can also have the conversation then about like which other small vips we want to include, and stuff like that.

but yeah, at a high level. That would be my my proposal.

Alex Stokes: It seems worth trying to me. And again, you know, we can force correct as we go. But there are failure modes with A/C today. So I think we should try to improve somehow. and we won't really know until we try it and see how it goes. I guess, on a related note is Marshall on the call. They had a post about an Ecd. Forum.

Marc Harvey-Hill: Yeah. Can you hear me?

Alex Stokes: Yep, hey?

Marc Harvey-Hill: Yeah, so yeah. So I wrote up this kind of brief post, which is kind of in in line with what Tim was saying, focused around involving stakeholders more in the process, like I think we saw with Eof, maybe like a kind of kind of failure there, potentially to get stakeholders involved enough, or like early enough in the process. And what I'm kind of proposing is to kind of create some new platform or website, potentially or upgrade potentially ethereum magicians to kind of be more specialized for Acd, and the reason I'm proposing that is, I kind of think that the existing channels that we have aren't necessarily ideal for getting feedback from lots of stakeholders. So we have these calls.

which obviously are like very limited in time. Maybe if you're just someone from the ecosystem who's not a core dev. It's a bit daunting to go on the call, or like you have to sit through these conversations about stuff you don't necessarily understand or involved or involved in and we also have, like big eth magicians. Threads which I think are also maybe not the ideal format for everyone to give feedback. So I think kind of the way we have things now is like. What I'm saying is we could improve generally the sort of ux I would call it, of interacting with Acd, and just make the whole process a lot more streamlined. So if you're some sort of random sorry, like stakeholder in the ecosystem, it's really obvious how you can get involved. You don't sort of have to be active in following every call like following ethereum magicians like. And the way I would imagine this is, you just have some sort of

Acd homepage or portal right? And it's kind of it will show you. When are the next upcoming? Hard forks are important, like what's proposed? You don't have to sort of cross reference between different forums like Github Repos. It's all in one place, and specifically for hard fork scoping. I think it would be useful to have sort of one canonical place where everyone can say their preferences for what should go into the fork. I mean, we have ethereum magicians threads. But the kind of way I see it is like, you can just see a high level like, you know, this is what all the different client teams are saying. This is what the L twos are saying. You know the the different

I don't know tooling devs, and it's all sort of grouped at a high level, and you can click in to kind of see the specifics. But you don't have to crawl through one big thread. So yeah, just, I guess, just to summarize like I just think that either on ethereum magicians or or some kind of new platform, we could just generally kind of like streamline things and make it easier for anyone to participate.

Alex Stokes: Yeah, I think that makes a lot of sense. I think it's tricky to know exactly what to do. But yeah, there are definitely a lot of ideas floating around around. making this more streamlined, making it easier to discover information. I know at different points in time people have discussed having essentially better records around eips because a lot of the work we do is Async. So just having that in like a easily discoverable fashion, I think, makes it. It lowers the barrier to entry for someone to come and provide their input in a constructive way. It's always you had your hand up.

Saulius Grigaitis: Yes. So so one thing that I think it often gets touched in some different angle. But I really lack wow of, let's say, last mile. when when new Eaps are proposed and even implemented. So so people, especially the core Devs, are really good at, you know, building software and coding and hacking things together. but it often lacks the last step which is like trying this change in the entire ecosystem, or at least a significant portion of of the ecosystem, and in order to figure out the impact of that technical change which often is, is good in the eyes of developers. Like some new cool feature and technical improvement.

but the impact of that to the, to the huge infrastructure that is, you know, that ethereum consists of is is often not investigated, and I think that this is something that that could help to you know, to to cut some features quite early, because, as as we already saw even a small feature sometimes bubbles to insane changes and into onto the shoulders of end users. So so I would like to see some improvement in the eip process, where where those who suggest the eips, they actually or maybe some other teams which hand over is the implementation. I mean be before there is a hard decision to to ship it, we we really should have much better final impact.

So that's the point I wanted to to raise.

Alex Stokes: Yeah, no, I mean, I think it's a good point. Historically, I think the idea has been like eip champions would do this. But I don't think there's ever really been like enforcement or compliance, I suppose, is the way to think about it. Because, you know, vip champions usually are pretty busy people. and then it's hard to do all this extra.

Saulius Grigaitis: Yeah, and it's.

Alex Stokes: Making around it. So yeah.

Saulius Grigaitis: Yeah, if I.

Alex Stokes: But yeah, I think there is a pretty general agreement improvement. There would be very helpful.

Saulius Grigaitis: Yeah, it could be even, you know, as there is this analogy with with testers and developers where you need to have a 2 different roles to actually ship the thing right? Because because developers doesn't think like testers and testers do not think like developers. So so it could be that that the IP champions even are not in a great position to to do that, to achieve that last mile because, you know, they actually motivated to ship, the the finger at at l. 1, let's say, without thinking too much, or or getting demotivated by the impact, by by the huge impact that we'll do in terms of, you know, a lot of efforts for the end users to support this new thing. So

so, yeah, I think this this needs to be considered, and maybe maybe we, we should introduce some new rules that that make sure that the impact is on on the end. Users is is right and acceptable, you know, and likely it's even not the eap champions, because they are not in a very good position to do this work in the right way.

Alex Stokes: Right? Yeah, or Vip champions supported or extended with others who are more appropriate for this type of thing. Tim says here he thinks we should enforce it for headliners, which I agree with, and I think even is this a screenshot from your post, Tim.

Tim Beiko: Yeah. So I think for the headliners. The thing I've been trying to get is some sort of like. it's almost like a wrapper around the eip like we should explain why the thing matters who's affected both positively and negatively. And then you know what's the state of of the proposal, and a lot of this doesn't quite fit within eips most of the time, because it's like these are big features. I think the their credit, like Vitalik and Danny have done this for the merge, like I I forget the eip number, but there was like a huge informational eip for the merge. yeah. So was it for the merger, the launch of the beacon? Sorry. I think it was for the launch of the beacon chain. That actually explained all of this extremely well.

I don't know that we need to go in that level of depth, but I think it's like maybe the closest thing we've had historically, to something like this that explains like, why, this is actually quite an important thing. And we should, you know, go on it on it. In that specific case I think they actually shipped it after the beacon chain went live. But it's still like a yeah good reference.

Alex Stokes: Cool any other questions or comments. Onsgar, do you want to say more about your latest commentary?

Ansgar Dietrichs: Yeah, I mean. And again, I think this is just my personal bias speaking. So, I'm not. I really am not convinced that I'm right here at all, but, like my opinion is that I think what we have not been good at in the past is like this, maybe less so than the roadmap forming itself. I think more the translating it to forks or something, because then everything and nothing is always kind of like, roughly related to what might be roadmap focuses. And then we have way, too many features, and we cut them down somewhat arbitrarily. For and then for me, personally, like this example of Maxib versus Pierres is just a very salient one, because both of them were kind of big Cl side features, and so they clearly seem to be in competition for the main kind of Petra Spot.

It seemed obvious from the roadmap side that Pietas was much higher priority. I don't. I don't think I've seen anyone within that had a different differing opinion in terms of like like impact from from the roadmap point of view. But because and I don't know. Like, maybe for randomness, maybe because Pdas was originally not scheduled for Hardfolk at all, but as like a side change that can be in between hard folks and that. That's why it was not as legible for the Ap process, or maybe because I had a comment to Sasha earlier in the chat that like, I think maybe stakers where we just have right now a maybe more easy access to Acd via the clients, because they're the main customers for clients compared to other users like L. Twos. And so maybe maybe, that those voices just were loud or something. It's hard for me to tell why that happened. But like the end result was that, like this clear priority just was not reflected in the ordering for hard folks, and so to me, that indicates that it's less about

the fact, like the the roadmap being the issue in this case at least and more. This kind of translation.

Anders Kristiansen: But again.

Ansgar Dietrichs: This could very well be completely wrong. Just my perspective.

Alex Stokes: Yeah, I agree with the general point. There's some comments in the chat around periodos versus Max Eb. But I'll just let that be okay. So I think a good next step here. I'll put Tim's comments here. I think this is like a good straw man. and perhaps one way. I don't know, Tim. You said you'd write up something for next week, and then maybe in the meantime, if there's any Async discussion, we could take it to the ether and d discord. Otherwise, are there any other comments on this? For now. if not, I think this was some great conversation to get this process started. and we can probably go ahead and wrap up earlier today unless there's anything else

MoD ask when we finalize for Sokka. So it's I would say pretty finalized, at least, you know, in terms of current. Sfi set for the Cl. I don't know if this is a question about the eel.

Parithosh Jayanthi: Yeah, I think we said that. When, as we get closer to Berlin, we should get closer to having everything that we want in Fusaka ssified and kind of locked in for now Fusaka devnet 0 only has the MoD Xp change. But on Acd there were already an indicator of at least one or 2 more eips that made sense to go in, but just didn't make sense on the timeline perspective. So yeah, I guess we do need to discuss that and decide when we finalize specs and just focus on shipping.

Alex Stokes: Yeah, that makes sense. And then, yeah, Tim just says on the next acde. figure out the other ele ips for the next couple of devnets, because that was kind of an open thread that we still have. Okay, are we good for today? If so, we'll go ahead and wrap up. Okay, thank you, everyone. I'll see you next time.

Marius van der Wijden: Cheers.

Ahmad Bitar: Bye.

Pooja Ranjan: Thank you.

Mikhail Kalinin: So.

Orest Tarasiuk: Yeah, bye, bye, guys enjoy.

Ansgar Dietrichs: Everyone.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.