EIPIP Meeting 115

Transcript

Heat. Heat. N. [Music] [Music] Hold

[Music] on. Hold on. [Music] Heat. Heat. [Music] Hey. Hey. Hey.

[Music] to EIP IP meeting number 115. This is issue number 1402 on

Ethereum PM repo. For people joining new here we have moved agenda to EIPIP meeting on Ethereum/PM repo. Uh so you can always follow it there. On agenda we have uh some open issues and pull requests to be discussed among the editors. some proposals which are in final status but we have received PRs to edit or update those uh EIPs and there would be some call for input. I have added a new proposal for discussion today that will be followed by EIP insight um that was requested by EIP insight

team. So starting with the first item on agenda, I see there is an update requested to uh EIP 196. The issue number is 8741. I wonder if any editor has any thoughts or comments on that. I still have no idea if this is correct or not. I haven't seen it. Okay. What is the next best action for the author of this PR? Like what can

he do to get this thing and do we need approval from authors of EIP 196? I that would be nice but uh who are the authors on this one? Um and I'm wondering why EIP. Yeah. Yeah. Okay. I think I have seen this and I approved it because uh uh as such it is correct because uh the coordinates are referred as x dash ydash in the second line and then uh basically they so in the same line when they're talking about the same coordinates they start they start using xy so I think uh the uh PR

is correct Okay. Um I'm not sure if I find any comment by Gajender, but if you would like Gajender, maybe you can add your comment and try to merge this if you find this good one because GitHub bot has already added it as a steel. So if we do not respond to it for a few more days, it might get steal.

Okay. Yeah, I'll um I'll poke somebody else um just so we have two people reviewing it and uh yeah, we'll merge it. Very well. Uh with that, we can move forward and the next PR U for Oh, this is just spam. It says spam. Okay, very well. 9539 the number is Yeah, I thought so. It's It's an issue. Yeah. So, we can perhaps close it. Yep. It's gone.

Good. Um, there are a bunch of open PRs for edits to final proposals. The first one listed here is PR number 9625, which is for EIP 3607. And it seems like it is uh authored by Dan Krad. So, I'm assuming that maybe the right input, but I'm not sure if this is for a final proposal. Yeah, this is this is fine. It's just fixing a typo. Yeah, cool. It might require one more editor's review or uh approval or would it be merged? I'm just going to force it.

Okay, perfect. Um, historical boundary [Music] definitions. Uh so you approve I think I already approved this historical boundary definitions. Yeah but it's not getting merged. Yeah it needs two. Okay so so that should get merged. And then the third one is another typo. Yeah missing I. So that looks fine.

And Danny is I don't know if it is okay to ping him for this small typo. I'm going to get so many annoying emails today cuz every time you merge um a PR, everybody else's repository who's a fork of the EIP's repository emails you and it's infuriating. Um the next one is PR number 947 and it's already might require force merge.

Yeah, I guess Tim renamed that repository and broke a bunch of stuff. [Music] Okay. 9614. Yep, that's [Music] fine. 638 So there is a special request for

9596. I think it's by the author that please do not merge it. Okay. Yeah, he mentions that he has already fixed it, so there's no point merging it. The last one here is PR 970 and it is for an ERC There's a lot of typos in this one. Um,

okay. Yeah, this is all good. So I think with that we are on PR number 9639 and that is an edit to a stagnant proposal. It's not active. Yeah, that looks fine to me. Very well. With that we can move on to the next section which is call for input. It seems like that we have only one open call for input and u one already closed.

The closed one is PR sorry the closed one is issue number 376. It has been rejected but uh the comment suggests that it can be revisited in future and people can always request to reopen if if there are more new facts in light uh for issue 381 Sam if you would like to again maybe summarize and it's it's beyond its deadline so what do we do now? Yeah I'm just cleaning up my tabs here. Okay. So 381 is the uh changing reference implementation. Um if I remember correctly, it's something to do with checking a

signature. Um no, it's a proxy call. Okay. Um anyways, it's changing a reference implementation uh in 6472. Um, we have two editors opposed. Um, and we've rejected things like this in the past. So, I will close this. Uh, cool. So, with that, we have all call for input issues closed. We don't have any new one as day. Um, so that's a

good thing. Okay. U moving on to item number two. Some other discussions and updates. Um I would like to provide some context. Uh here I would like to propose a proposal and the context here is um there has been recent discussion in all core meeting about reconfiguring all cordex. they had certain they had discussed certain ideas and it was uh discussed in um in a fellowship of Ethereum magician post uh authored by Timbeo. So um so uh I have uh added a comment over

there if we want to if you want to like uh I'm I'm not sure is everyone able to see my screen right now. And that is with an optional preamble header stage. Okay. Uh where was that? That was on uh Ethereum magicians. Yes, that's correct. Okay. Okay. So, I have added the link here on Ethereum magician uh reconfiguring all cords. So there I have proposed an idea of including

um preamble header called stage. The reason why I'm suggesting this that it will help all EIPs to be kept track of independent of going into each of the meta E when it was considered in the past. So EIP 7723 which is network upgrade inclusion stage talks about different stages that any core EIP will go through in the process of planning network upgrade and these stages are proposed for inclusion consider for inclusion scheduled for inclusion decline for inclusion and included finally. So um the proposal here is to add a preamble field to EIP template and that preamble field will be called as

stage. So the input that we could provide to this stage would be um like the upgrade name and meta e link along with the network upgrade stage. For example, if a proposal if an EIP was considered for petra upgrade but um within um the community it was not accepted for whatever reason like it is not ready or it may not be a good fit for that particular upgrade and that was declined for inclusion. But now it is being considered for inclusion in Fusaka upgrade. So we will get a history of that um EIP's consideration for inclusion um like how how it was um

declined and when it was included the entire history. So this proposal is just to add a preamble field called header header and um and I have suggested that the um accepted input could be here. I have added the link to the document in in the agenda if people would like to take a look and maybe uh give feedback on that. The idea here is for example if there is a proposal then we can have this um field stage where it will be written Fusaka and in Fusaka it is CFI but in Peterra it was DFI. So DFI is declined for inclusion and currently it is CFI that means it is um considered for inclusion and let's say that this

proposal is being included in PECRA then the final update here when the proposal will move into final stage status it would be Fusaka included and PCRA DFI. I'm curious what people think here. So there's kind of a technical barrier. Oh, go ahead. Sorry. Yeah, sorry. Uh before that we talk the technical things my my viewpoint is that it would basically you know force people it would put stress on people not to propose the proposals because people can

see that okay you know DFI they they will start considering as a negative score to the EIP and while it might not be a negative score uh so in that sense I would not like to I I would not basically like to retain the history as such. Maybe the latest state later status might be good enough. I would argue against this. The reason why we wanted to I mean I proposed to have this status because there are certain proposals they are good. It's just that it was not being considered and they are being deferred

again and and again and again. So when this proposal is again resurfaced say for example two upgrades later then people will understand that this proposal has been waiting for two upgrades. It was ready. It is a good proposal but it is it was not um included for um other reasons like priorities are not there and yeah but puja I mean whoever is the EIP champion always is is very easily able to you know say this thing that you know we have been doing this and all these as such ACD community is very well aware of the proposals that come again and why they have come again or why they were refused earlier and the Champions definitely try to put their best foot

forward in that sense that they try to push for it. uh I I mean I don't think in terms of ACD consideration this header makes any sense but uh I would definitely think I would def I definitely see that uh that in uh that if for example if there are many DFIs then people white might start to negatively view such proposal just because it has because of this particular history that has been built up with it. I think we don't we don't want that.

We I I'm not sure how to best build a history for it and will it will it really help? But maybe final status or I think instead of saying DFI, CFI, if we let it just be CFI or PFI purpose or inclusion, then uh we we don't have a negative marker. So we can accumulate these history updates but without the negative marker because uh if it's if it's associated if the final status is if the uh status such as PFI or CFI is associated with the upgrade that definitely means that it

didn't go to final but DFI basically is a strong negative indicator in that sense. So I am okay with this history but without the DFI indicator. Um one noticeable point here is like DFI is already there and it is part of hard fork meta. For example, if we are looking at hard fork meta foraka uh it list a bunch of DFI. So it will be there. Of course, the idea of having the stages would be uh like in clearly stating if people would like to mention like find history, they can easily find it. Yes, Victor, please go ahead.

I kind of felt that Ginder and Po you both thinks this is valuable. Oh, I uh Genderra, do I understand you correctly that the decline uh gives us negative sense is what you uh want to avoid. Yeah, I think I I I mean I'm if I would have been also uh I would have been uh there while it was being well declined was being introduced, I would not have voted for it. I mean I I might have been there but I didn't notice it but uh yeah so I am not in favor of DFI otherwise

I'm okay with the the history accumulation. Yeah. And Puja, I think you bring up a point where sometimes having a history of DFI actually signals um the long effort and attempt uh and track record um for some the the advocates of that of a specific EIP. Having DFI actually signals that okay a lot of efforts put in and they have been waiting. Is that a good understanding of your side?

That is correct. Uh and I would like to add a point here um that may help Gajjinder. Gajjinder the DIY status is still here which is a part of EIP 7723 which is not finalized. It is still in the last call. So if we do I would definitely raise a a concern about that on that proposal if you don't like decline for inclusion. Yes. So if we don't want decline for inclusion we can perhaps delete it right here. It is not finalized yet. I I wonder um I wonder if based on the understanding between Gardenders and and Fuja whether we can find a solutions that address the concern both of your concerns at the

same time by changing the name for deferred for inclusion to uh from from decline for in inclusion to deferred for inclusion meaning this is great change yeah it's still DFI it's still DFI but it's deferred. Um and maybe if the AD maybe if the the the ACD uh meetings won't have a strong version they can have a rejection reject for uh rejected for inclusion meaning like this is not going to be in uh included at all. We don't consider them at all. Um but if something is good just we because we don't have the priority and capacity to

do it they should be deferred. uh if they're not scheduled and rejected. Yeah, I think I'm good with that. Yeah, I see no problem there as well. So the proposal is first uh consider changing decline for to defer and if if maybe the the ACD will say okay sometimes we really want to signal we don't want to do that then also consider adding a se a new status which is rejected and that's a strong word don't come back.

So yeah, I think we can we can we can bring this back to the to the feedback if if that's that that's good to the to the proposal. Puja, are you the the proposer of this or uh is it did this come from um you and and and team bake hold together and and like who should we give this feedback to suggest suggestion to? I think we can perhaps make use of this fellowship of Ethereum magician page right here uh which is for discussing this proposal when it was first proposed and we can make use of this page because this proposal is still not finalized. we should definitely uh offer uh the change that is discussed here in this meeting today. And just to

give some more context, this uh decline for inclusion was discussed in one of the meeting I believe in uh Bangkok and uh it was proposed right after the defcon. I'm fine with having it with a deferred. However, I feel like the definition added here definitely indicates about deferred. doesn't mean that that proposal can never be um considered for inclusion. Yeah. So, let me document it down and send it as a as a as a reply. Uh so, God gender suggested decline my signal have a have a negative signal. U want to maintain the record to show the effort

continuous effort of author. So combining that we suggest uh maybe consider using a defer and if defer is not enough consider also adding a rejection. Is that a good summary? Yeah, I mean that cool. Sam, do you have any thoughts on that? Um not really and not directly anyways. I'm I'm writing up a comment.

Okay. Cool. Okay. So that is with respect to EIP7723 a feedback coming from EIP meeting. Um having said that uh I would like to go back to the proposal here. Uh this was an example like uh to keep track of all the stages. So irrespective of what we are calling here is DFI. Do people generally agree that it would be a good idea to keep track of stages? Uh so I mean like generally stages would be helpful to keep track of an active EIP. For example, an EIP is being considered for Fusaka then it will also undergo different network stages as

explained uh in in EIP 7723. Um and having that status can be having that uh field can be actively maintained while the proposal is not finalized and once that is finalized it could be included or it could be DFI. So my question here is like are people generally okay having the field stages and then we can definitely discuss upon what should get into the input for that what what are the accepted input for this field stages or a stage not s so my objections to having a field um

are kind of the same as they've always been um there's a permissions issue with having a like network upgrade third stage preamble header and so there are two people who can be resp or two groups of people that can be responsible for that header. So either you have the authors of a proposal being responsible for that header or you can have the editors being responsible for that header. If the authors are responsible for it um meaning they can change it without having to get PR approval. They can set it to whatever they want. they can say like, oh, you know, it's scheduled for inclusion in Prague even though, you know, nobody's just wants it in Prague. Um, that's a problem. Um, because it can make it can be

misleading, confuse people, whatever. Uh, on the other hand, if editors are responsible for approving uh changes to that header. Now, the editors are in a position to determine what the sentiment of all core devs is. Um, and that's kind of a subjective thing, and I don't want us to be in that position. Um which is why we have these meta EIPs for hard forks uh because they don't have this permissions issue. Anybody can propose uh a meta proposal for a hard fork uh including and ignoring whatever proposals they want. Um and core developers can follow and ignore whatever meta proposal they want. So, like, you know, some random person could propose, you know, uh, I don't know, uh,

a Toronto upgrade and everybody would ignore it because Tim didn't make the proposal. But EIP editors aren't in a weird position where we have to determine whether Toronto would be a valid hard fork. Um, but what we could do is add some UI work to display the status of proposals um, on their pages. I just don't want there to be a header field for determining that. Um I would like to quickly respond to this. Uh so u I I take the concern here is responsibilities and permission. If this is to be added as a field, I would believe that the responsibility will lie

on author and uh the verification can be done. this link that we are trying to add right here directly takes us to the um meta e of that proposal. So if an author is suggesting that this EIP is being considered for inclusion for fusaka then this backlink should take us to the meta e of that fusaka. So that we can always verify and when we go to meta uh link of Fusaka it talks about that whether this proposal is included I mean whether it is CFI or not. So uh we do have a way of verification and we do

have a way of adding this responsibility on author based on the meta you have to update your um header field just like we give this responsibility of adding the last call for a proposal like when you are adding a last call it is up to you that you count plus 14 days and make the right entry. So you have to make the right entry over there. At the max editor's responsibility if it comes there then maybe if if they are not happy they may crossverify it and this thing like this meta e for any upgrade is being updated every um week by uh whoever is championing the proposal. So if it is not Tim Beo who is the author

of this proposal, his responsibility is to keep it updating and make sure that all EIPs listed here are up to date. Um we do have an option of uh puja I I don't get this one every week but someone has to do work. Uh it's for meta author like uh for uh including the decision from all core dev. So for example in all code no but even if Matt you know even if uh so for example Tim BCO will have to do some action on the meta EIB every week. Uh yes yes if there is a change from the existing list that is discussed on the all code dev meeting. So now the all so

only if there is a change he's not really required to touch it every right no no no so what the way it is being reconfigured the all core dev is that in ACD meetings only upgrade related discussion will happen so most likely the discussion will be around the EIPs and their different stages so there would be a bunch of EIP proposed for say for example Amsterdam in upcoming meetings so there will be all part of Amsterdam meta e and they would be all part of proposed for inclusion or considered for inclusion. So the way eventually it will move from one stage to different stage it will be the

responsibility of the author to update this meta to reflect the correct stage of that EIP and uh um uh again sorry to interject but as Sam is saying what we are all doing is basically we are saying that uh Tim Bos's meta ape is the canonical one. Mhm. So we have all decided whose meta is canonical one and that is something that Sam doesn't want to do and I think I'm with Sam on this. We are not to decide who's has a canonical meta e and uh if there are many metaeps right now we don't have but if there are many metaeps floating around and somebody might link it to that and it will only create confusion because it might happen with the they

might propose for the same upgrade and it will have the same thing and it will take them to a different meta e for sure but it will definitely uh bring confusion to the table to the EIP uh reader. Um I mean personally I doubt that there could be two meta for one upgrade because that would not be approved and merged as as draft in the first place like we can yeah we would no definitely I think we would right yeah ex yeah oh am I muted I'm probably muted oh so we are worried that there could be a possibility of

having two meta E for one upgrade. Yeah. Or or just two upgrade Ess going at the same time, not necessarily for the same like epoch or slot, whatever. Okay. Okay. Maybe um I'm just trying to understand it in a better way. So if there are two upgrade going on simultaneously if they are not supposed to be on the same epoch slot or maybe at different point then the list of EIPs will be different they wouldn't be same.

Well, okay. So, like let's say uh let's say there's a very contentious EIP, let's say EOF, right? And then you have one camp of people that uh want a hard fork with EOF and you have a different camp of people who want a hard fork without EOF, but everything else is the same between the two hard forks. There might be two metaeps describing like a similar thing, but they don't necessarily have to be on the same block. I get it. But I think this is the problem that Alcorev is trying to solve here that if there is a decision it should not be like um uh we had this situation long ago. Uh but it should not be like that. If there is an agreement

there is a general agreement by all client and we should have only one meta for one upgrade. I what was the name of that uh EIP? I think it was in 2019 when half of the miner agreed that they would be um doing that but Ethereum client defs decided not to go ahead with that anyway. Okay, cool. Um so uh I I hear that there are some concerns and people are not ready to have this field. I believe uh the alternative suggested here is is an okay way to

maintain it and we I think EIP insight is in a way maintaining that EIP is in in this particular upgrade. Um we can also add that uh as what stage as per that meta e that EIP is being included. Is that the summary or if there is any room for like if we solve any particular problem we can perhaps have this feedback. Yeah. In that sense if for example we recognize one set of meta eips as canonical uh basically then you don't have to do it on the uh on per IP level this can

totally be sorted by the website renderer and it can inject the fields if it wants to and sort of create them. uh in that sense I would basically so what what I'm what I'm saying is that without incurring additional overhead on uh human resources I mean this can be rendered uh by the code itself. So if we have to do this then I would just say that our uh HTML generators will autoop populate these fields. Yeah, we can we can do that. Yeah, I agree.

Yeah, I think the main u reason why I wanted to have this field was to contain the history of that EIP when like how many times it was considered and how many times it was deferred and it could not be included. Uh otherwise yeah so that can still be done because you would have a list of meta that the channel generator would consume consume and sort of generate these fields. Yeah, I think it can be doable if we start from here because this uh EFI, CFI and DFI history is started from PCRA EIP only. So yes, that can be done very well with all this discussion. It seems like

we are in agreement to have a um have a request to update DFI as deferred for inclusion rather than declined for inclusion and uh addition of uh addition of uh a preamble header is uh not a requirement that can be managed by UI. Cool. Uh with that we can perhaps move ahead with the next item unless anyone has anything uh to add last minute. Very well. The next item is

stagnant part issue. Um it was discussed in the past two meetings. I wonder if there is any update. I see we've been on the call. Yeah. Uh sorry about that but we didn't get much uh much time to work on that. So uh we'll try to work on that before the next paper meeting. We got uh other things to do uh for our website. So we we got less time for this contribute contribution. No worries. We can um see if there are any further updates in the next meeting.

The next item listed here is an announcement. For people who joined last EIP editing office hour are already aware of it. But uh for people who missed that earlier we used to have two EIP editing office hour in a month. That was for EIP plus ERC editing. A few months ago we added one more of EIP only meeting. Now I'm happy to share that we will have EIP editing office hour every week and in alternate weeks we will have for EIP only and EIP plus ERC. We are getting support of editor Sam Wilson

Gender Singh and Matt Ganette to continue this EIP editing office hour and bring it every week to you. So if you have any questions, comment, concerns with respect to your pull request or curious in general to learn about the process, you are welcome to join these meetings. This h this will happen every Tuesday at 1600 UTC. Moving forward, we have EIP insight uh monthly EIP status reporting as well as some other updates. Those were requested. So yeah, V take it over.

Yeah, thank you PJ. So uh regarding the updates, we have added this new chart EIP uh label distribution and uh what this chart chart means is that we'll be prioritizing the PR based on the labels and we'll be providing a downloadable reports for that. So um like it it it gives a priority order in which the PR labels were created and um based on that they were categorized and the rest of the uh labels other than the specified ones are considered as

miscellaneous so that uh the data will be same and it can be downloaded. And regarding the second update, we have added this new page. Uh like this is not live yet. We are still working on this. This is for keeping track of the hoodie test net and um like the core idea for this one was keeping track of the transaction trends. the uh like for looking uh if there are any type four transaction especially which were included u using pectra network upgrade uh we wanted to keep track of that so we started working on that and um this is

an overview of that so like the data currently we have is for the past 24 hours it can be adjusted and keep track of that and also other than this Uh we have also added this new chart where we can keep track of the base fee, priority fees and gas used and gas burnt. Uh it will be providing an overview of the amount of gas uh burnt or used in a particular block. Um like as you can see for the hoodie test net all of these are fluctuating at an equal rate. uh like this they were fluctuating at a similar rate for all the blocks and this trend uh continues

for the past 24 hours. Currently we have it for the past 24 hours but uh we'll be adding for around a month like we are planning to add it for around 1 month like that so that uh you can keep track of that and other than that we also provide details like current block information recent transactions and recent blocks like that. So uh like we we also wanted to request for an input from your side if we can uh if this makes sense or uh what should we add so that we it will be more useful for uh the Ethereum community like that we

actually wanted to uh request for an input from your side. If there are any inputs we uh we'd be happy to take it in. I mean this looks super cool. It's neat seeing it uh sawtooth like that. Yeah. I have a question here like when you are keeping track of different transaction type I believe they are coming up from different EIPs. Will there be a way to showcase like uh which EIP um was used for that?

So these types are based on particular EIP numbers, right? Like type four is for 7702. So like this itself directly means that uh number of transactions in each block that uh that belongs to a particular EAP like that, right? Yeah. Yeah. I don't know if this would be possible to have a chart to get the trend of all these EIPs in a way like you know type zero to type four. Um u showing like what what are the what is the number of transaction included per block.

I mean it is like that but for some reason I feel like it will be better if we can see it horizontally and only four or five lines are there. Yeah. Uh like a line chart do you mean? Yeah kind of. Yes. Yeah. Uh yeah we'll try to make option for both of them like so that you can switch it and uh check them. Yeah. And my recommendation would be like you know get in touch with because this is related with hoodies. So get in touch with Partoshian team who are actually working on hoodie network right now. And if they may have suggestion or if they may want to keep track of any particular type of you know data then you can perhaps provide that kind of

dashboard to them. Yeah. Uh yeah I'll be doing that. And regarding the next part of the discussion, this is the monthly EIP report, EIP status changes report. So um there are six EIPs, three ERC's that were moved to draft stage and eight EIPs, one ERC that were moved to review and one EIP and one ERC that were moved to final and three EIPs that were moved to stagnant stage. Uh you can also get the downloaded report over here and it will be looking like this. We uh

categorized it based on the report. So it would be uh more detailed if you want to check it out offline. Yeah. Uh and also we are also rolling out u tweet every uh half month and at the end of the month so that uh it would be visible to the community more. So uh we also shared the Twitter link in case if you want to follow that you can check it out and follow the inside Twitter. Yeah that's the update from our side.

A quick question I noticed there was no change in RIP. I mean was there no change? Uh just curious like everything was I believe there was no change but uh I'll check just in case. I'll check our code base and if there was any error and it stopped functioning but it shouldn't be a problem actually uh like it should be running without any errors so I'll be checking and update you with that sounds good thank you so much yeah and also son uh the bug that you mentioned that was cleared I appreciate it thank Okay. Um with that we can perhaps move

on to the next one which is the AIP editing office hour. Um agenda and video should be there and um yeah I think that brings us to the end of the meeting. I wonder if anyone has anything to add, question, comment, concern, anything that we can discuss in the next meeting. Yes, Mercy, please go ahead. Okay. Um, you did mention I think last week it's about the reviewers. So, I wanted to know if there's any update on it. Did you mean the dashboard for reviewer?

No, you said something about um like a kind of like interview or something for the reviewers. I think uh I'm just trying to understand is it like how a reviewer can become an editor? No. Um you mentioned about finally moving the re um some of the reviewers to um editors. Yes. Yeah. So how we can move a reviewer to an editor? Yeah. So the basic idea is like we would like to uh follow the reviewers work for next 6 months um since they have started making contribution. Good

thing that we have the dashboard. dashboard will help us keep track of their ongoing activities and at the end of six month if they are interested they can definitely propose themselves to become an editor and there is a process like they may have to update certain files to get necessary um permissions and that's a high level process of getting converted from reviewer to an editor and obviously it will require consent of all the present editors they should approve Yeah, I guess the only other thing is to probably start leaving um comments on calls for input uh if you haven't already been doing that. Uh but there

haven't been many of them. So, sorry, I didn't really understand that. Sam, can you come again? Oh, sure. So, um there are the calls for input on the EIP IP repository. Um, if you would like to become an editor in the future, it would probably be a good idea to leave your opinions on those topics as they come up. Um, but there haven't been a lot of them recently. Okay. Okay. Thank you.

Yeah, that that would be a good idea in addition to your continued contribution which is anyway being tracked separately. Any other question that can be answered today? Very well. In that case, thank you everyone for joining us here today. We look Oh, hang on. Um, I would like to uh mention that uh the new version of the EPS website is pretty much ready to go. Um, and I'm looking for people to test it out.

Um yeah, it's um there's a comment in the Discord about it, but uh I'll post another link to it here. Um but yeah, um basically I'm just looking for objections or uh feedback uh about whether or not we want to switch to this. So um there's a link in the chat and take a look. I'm going to add the link uh in the comment section of today's agenda so more people can take a look at it. Would it be okay to include this as um like decision making point or agenda item for the next meeting like we can decide on

it? Absolutely. Cool. Yeah, I can make a call for input forward if if we think we're ready. Sure. Thank you Sam for this. It was long due. I look forward to have this switch but obviously we need to make sure that everything is in right place. Cool. Thank you so much for this. Um anyone has any other thing to be added either any suggestion for for the next meeting that we that we can add as an agenda item. Very well. Thank you everyone for joining us here today. See you all in next meeting which would be scheduled

for May 21st at 1400 UTC. Have a great rest of the day [Music] everyone. [Music] Hold [Music]

on. Heat. Heat. N. Heat. Heat. N. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] [Music]

down. Hey [Music] Hey hey hey. [Music] Hey hey hey.

[Music] Oh yeah. [Music] [Music]

Move [Music] on. Hold on. [Music] Heat. Heat.

[Music] Hey. Hey. [Music] Hey. Hey. Hey. Hey. [Music]