EIPIP Meeting 54

Transcript

welcome to eipip meeting uh 54 i have shared agenda in the chat for people to refer to the first item that we have for today is co eips in an executable spec world so uh this was proposed a few weeks ago by timbeko uh there is a proposal and the link is added to the agenda uh we can check it out and this has been under discussion from past few weeks in the last meeting uh greg shared some concern for people having to learn python to be able to contribute to the execution specs but we were short on time to continue this discussion

hence i have added it for today's uh discussion so yeah if there are any thoughts sure so greg and i had a um discussion after i think it was the last eip ip meeting about um you know how python fits into the eip process and how it's not really a great fit for um all types of eips so um one thing we were considering and i don't want to speak too much for greg but um is possibly allowing a diff against the yellow paper or the python spec in the eips um

that might be one path forwards um i don't know how anybody else feels about that but that's basically the only update that's happened since uh the last time we spoke about this right i see there are a few questions that uh those are being discussed one is about the eip number i think there are some certain suggestions for that and then some improvements that could be made with the help of bot so if you can maybe summarize what is the proposal on on like higher level and the way we are trying to move forward oh sure uh i mean at a high level i guess the idea would be to change the eip process so that instead

of it being an english test text description you'd we we would first start by splitting the eip process into two parts core eips and non-core eips uh core eips would live in the execution specs repo well so this this is my proposal it's slightly different than tim's um but mostly the same but in my proposal you would split the core eips and put them into the execution specs repository um and then the eip numbering proposal i had there was basically that if you have an eip that spans multiple uh each eip number would encode whether it's a core eip or an erc or a consensus layer eip like

um so you'd have some extra information in the eip number and then you could use that information to find out where you need to look for the eip and then the eips would live either the consensus layer specs repository the execution layer specs repository or in some erc specs repository um and the reason why we want to well i'm proposing we split it up like that is to um keep the standards close to the code that defines them um yeah i don't know if that's helpful or not but that's kind of the summary of the eip numbering change do we have to retain numbering between when we make the switch can we

start over from one i'd like to keep it one application inspect two what do we gain by keeping it i was worried there's a lot of complexity in keeping it long term and if we could just have a different numbering system that seems easier i i don't feel super strongly about it i think i'd like to keep the eip numbers like and just have like a legacy set and then a future set but like i don't really care that much i think my my biggest concern is about how we're actually going like are we going to put execution specs into the eip process or not and i think that's a much bigger question than how we're

going to number the eips sure yeah i think we first need to a list of the questions that we want to be answered first in order to progress in that direction because it seems to me like there are too many things that we want to address at the same time and we are not clear on which path we want to go all right i mean i guess the the biggest question is do we make um a diff to the python spec a mandatory part of core eips and then everything else is kind of secondary to that manga do you have any thoughts on that

making diff to the python spec to exist no i have no problem i have no problem with python specs i would like my personal desire would be that um execution sex repo handles everything and that is both the actual technical spec and the human ruble stuff i liked the way sam proposed it previously which is just the markdown files in there so i think sam and i are mostly aligned at this point okay would you agree with that tim i think so i have one more curious question here so uh we are talking about having um like execution specs for core eips only so what do you guys think about having

just for core eips there and uh for rest all of the eips including interface and networking eip following the same process as they are doing right now or are we planning to have uh networking and interface be a part of execution specs i don't believe there's any current plan to move um any of those into execution specs one can imagine the networking probably being the next reasonable thing the interface stuff in terms of json rpc has kind of already moved out of the eip's repo so that's already on its way out to another system i have seen couple of uh interface proposal i suppose for the exec

consensus layer specs this is i've i've argued on those issues uh i so it is part of the reason we need to settle on something is because the uh condensed player does need a place to do their you know have their change control process in some way and some people want to merge that with the eip process some people want to keep it separate and then things get even more complicated complicated when you have some change set that includes both execution and consensus layer changes where you keep that document and so that one people are kind of pushing into the eip's repo at the moment not a huge fan of that i would keep it out but

there's i acknowledge there's not really another place to put it at the moment so if i understand correct at the moment for execution uh layer specs interface proposals are already moved out of the present eap depository however for consensus layer json rpc stuff is moved out only only json rpc okay yeah so other the interface and theory includes other things um though not much that json rpc is the bulk of it but hypothetically there are other things that fall into that category right so giving the benefit of doubt there is still room for interface and networking

eip with erc uh eats process i guess i mean i don't so so yes i mean that i i'm not sure the eip process is ideal for either of those just like the execution executable spec i think is a better solution to the problem of coming to consensus around specification i think the same is true for the networking stuff i think the networking stuff would be better off if there was you know a canonical document that ideally was computer readable similar to the fusion stack it would be like the networking spec and that had some sort of change control process built into it again just like the execution executable spec that's being

built um however we do not have that today and we're not there today and so since the eap process is basically the only change control process we have at the moment everything is dumped into it and that includes networking which i don't think is good fit and historically interface which i also don't think was a great fit so yeah like it's one of those things like we have nothing better it's not it's not a great solution but it's a solution that exists well it looks like that earlier we were in a position where we were thinking of moving eip and erc separately now we are trying to pull out

just the core eips from the existing uh change control process yes at the moment we are only working towards pulling out um core eips uh because with through the execution specs and again we we have already sort of pulled out the json rpc stuff which is the majority of interface and hopefully one day in the distant future when we have infinite engineering resources we'll also pull out the networking stuff all right well this is good at least we are very clear on this part that we are not going to change the entire change control process the proposal is just for limited to core eips only at the moment whenever

we get chance to update the networking and other interface eips will look into that so this is clear this is really good and now um we if we discussed about two proposals i think not two distinct proposal some somewhere overlapping so yeah in that i mean like on those two proposals the point of disagreement was including diff to python spec um i don't know i'm not an editor not a nor in developer but from where i'm looking at it it looks like because we have this yellow paper written only in python spec right now that is available with us it seems like a

fair compromise but yeah if you guys have any other thoughts on that so so greg did bring up the point that we do also have the yellow paper so we could theoretically you know use diffs against yellow paper as also an acceptable way of specifying things but yeah for for the listeners the [Music] primary argument against that is the number of people who can functionally read the yellow paper is like 10. the number of people who can functionally read python is you know millions maybe not millions hundreds of thousands um this in terms of notation and general understanding within the

developer community python is just significantly higher than the mass notation that the yellow paper uses like it's basically it's more accessible like the python is far more accessible than mathematics and greg's not here is he like no okay so his argument against that would be that the yellow paper is currently poorly written and if we devoted as much time to maintaining the yellow paper as we are to the python specs we would have a much more accessible yellow paper i would be curious if that is true i am not convinced like if i imagine myself rewriting the yellow paper to be more accessible i would i find myself ending a python or something along those lines

like i don't see a path it doesn't take you to just use python or just use typescript or whatever um i i mean so if i were to do it you know with infinite engineering resources i think um doing it in a formal spec language would be like ideal like something like k or uh daphne or whatever and that you know you could actually use that to formally verify code and that would be the best option um but no one knows those languages and they're not accessible um so yeah right so if i i can be convinced i think that writing in something that can be formally verified has significant value

i do not think it solves the accessibility problem at all so yellow paper is either accessible nor formally verifiable and the python spec is accessible but not formally verifiable and so i would say that strictly better and then there's a third option which is formally verifiable but not accessible and i can see a strong argument that that is a path that one would want to take over non-verifiable but accessible and in a perfect theoretical future somewhere rainbows unicorns we find something that is both accessible and formally verifiable and i think you know the possibility of you know taking off my i'm pretending to be greg had here

personally i think you know there's no reason not to use python in the meantime until we find something that satisfies both both accessibility and formal verification so yeah i guess the one of the other things that i go ahead sorry if you had to pick between accessible but not formally verifiable or formerly verifiable but not accessible is it immediately obvious to you which of those is better or is that something that like you would see are good either way like are you in the fence i i would say i'm on the fence about it like from a theoretical point but i can't make the formally verifiable spec so obviously i'm going to work on the

accessible spec there were two people that you let's say you finished the actual spec and at the same time in parallel greg finished the uh formerly verifiable spec uh formally verifiable which one i would choose definitely the formally verifiable one for me yeah you think so okay but i don't think we're ever gonna get that so if anyone out there listening uh wants to devote a massive amount of engineering time to write a formally verifiable specification for ethereum it's a desirable thing apparently yeah yeah and i mean we have the foundations of the evm and k already somewhere so that might be a good place

to start but there's a lot more than that um but yeah i don't think we're i'm sorry it's very confusing because your zoom icon is pooja's zoom icon and i don't know what's going on with that and it's funny really uh yeah it doesn't switch it just he's pushes um yeah uh so you know if somebody wants to come along and have that ready then i will gladly support switching to it but in the meantime the yellow paper i think is the most useless uh an idealized yellow paper i'd be much more supportive of using the eip process and obviously i'm very supportive of using the python spec in the eip process

so it looks like we are at a point where we have executable specs in python and may be looking for someone who can write specs informally uh very like formally verifiable uh specs can be written with the help of yellow paper yes but just to be clear that is a monumental task um and so while i put it out there if someone like has a background in this and really wants to get involved in ethereum um this is maybe a place but this is like a very big death this is definitely not a small little thing that hey we need someone to help out a little bit this is like we need someone to dedicate two or three years of their life to build this thing

well i think this particular argument gives us some flexibility to go ahead with whatever is available as of now because i understand this execution table spec is being written for over six months and now we are at a place where we are assuming that we will be um finishing up with all the upgrades and we'll be reaching a point where we can migrate the process i mean like bring the query ids to this process but if we start today for with yellow paper it will take another six to six months to one year down the line i would say more than that to get formally verifiable i mean i'm definitely not an expert in that area but i would guess years of engineering effort

it's unfortunate that greg is not here and uh i'm really um a little hesitant on like uh coming to a a general agreement when we know that we have someone who has a different uh thought maybe we can bring it up in the next meeting but from from today's discussion it looks like uh moving in the direction of python spec i mean a diff to python spec is probably a good approach at this point anything anyone would like to add on or if there is

i don't know how do i put it like maybe uh kind of uh call to action that we can do from the community looking for people who can start working on it or maybe voting kind of collecting uh some general opinion what is the preferable i know we have limited people on the call and we get to hear what they think about but in general if people are looking for getting more opinions we can do that the categories can look into that part but yeah i mean all i can say is you know um i'm gonna keep working on the spec well along with the other people who have been volunteering on it and uh if it becomes useful for the ap process i think we should adopt it but

i think working on this executable spec is a very good idea and we should continue doing that thank you for you your team and so many other contributors who are working on this and maybe we can share the recording of it with some other people and if needed collect some more opinion from different editors and we'll also share it with the client teams if they have any preferences and we'll try to bring it up in the next meeting let's see if greg will be able to join in in the next meeting maybe we can have a consensus then probably will focus on which particular uh process to

be adopting because i understand we have almost two proposals here sounds good to everyone yep yep all right thank you all right uh moving ahead the next item listed here is should we discourage the word standard in eip titles and descriptions i have added the issue so this is collected from the eip github repository where we are asking people to add issues which can be discussed in eipip meeting brought uh in front of eap editors so sam has created this issue and i already see

comments from mike and sam going on not sure if there are different opinion but yes i'm if you would like to talk a bit more about that uh sure as an eip editor i find it incredibly annoying that the word standard shows up in the title of every single standard that's proposed so i'd like to just add a note that we discourage the worst standard in eip titles and descriptions can i support that yeah i mean you create a pr i'll prove it and then i guess if you create a pr i'll thumbs up it because our approval stuff is kind of broken free ip1 that's right uh yeah so this is basically a proposal to amendment to eip1

and um yeah this sounds like a fair ask yeah thank you micah for suggesting solution here okay let's see if if any other eip editors may have different opinion they may respond to the pull request and we can take it from there the next item listed here is eip bot issues and eipv issue updates and agreement on the process to merge and close so uh now ethereum cathedrals have been looking into some issues uh at eip bad github repository and eipv repository we have jose on the call who has been looking into these issues and

he has been trying to close the issue so we are um looking for a proper process or maybe kind of agreement on how do we proceed in that direction earlier it was alita and she had uh the access to maybe close and merge pull requests everything else but now it is limited um i would pass it on to jose for his concerns and opinion thoughts whatever he ever observed so far thank you yes each issue 58 and issue 53 they are pretty much the same comments could be written in the

in the repos so you guys can agree on it or not issue 55 is is a complete modification of the copy copy edited capacitive of the bot is basically the the list for this action has been pretty much close up there is just one pending issue about the pdf file and i haven't said that this morning

oh i don't know this afternoon depends uh panda pit just uh comment that basically or maybe we use we just can split this issue and queue one that includes the all the actions already pretty much agree and the other one to open the discussion for the pdf file great was not liking the idea but well i guess that if we just create separate separate action we will be able to talk about it and to get an agreement and the last but not least signs the last call two issues were

closed issue 60 and issue 61 that's pretty much about it i do agree that uh it looks like this enhancements um issue number 55 should be split up into multiple smaller issues that are more targeted so we can discuss them separately yeah i think actually one per uh numbered item in the comment that i posted would probably be the most appropriate yeah yeah i weakened it good i can do that if there's no objections none for me i would i would like see it

also makes it a little more consumable for new people that are trying to help out allows them to make something easy and tackle it and feel a sense of accomplishment it's an excellent point yeah so i'll do that i'll split all that up into like 11 or 12 different issues and then we can discuss in the various threads does that work for you uh i'm assuming jose but i'm not sure yeah yeah yeah that's fine thank you uh please also take a look in the between 50 a.m and 53 they are pretty much the same so we can just close one and leave one open as a to take that action

okay 58 and 63 you say are the same 53 53 cta that's the one about the adding or populating the co-owner's file with the editors just together they're very very much the same is the code owners i see that and then five three is editor approvals required for ambiguous prs is that correct yes when when you see the discussion till the end there was some [Music]

comments and agreement to basically just do the same i see okay yeah i'm a little bit behind on maybe it's a good segue anything else on the topic that's cool for me thank you so yeah um i'm assuming like i'm just going to use this as a segue to get into that's not on the agenda but before we move into the insights and

differentiation stuff um i am like two weeks behind on eip editing i've got my inbox has like 200 emails in it that i need to go through um we could really use a full-time editor i know sam has been i think sam does once a week which is definitely helpful like matt has been maybe once every couple of weeks and that's basically it i think and so uh if anyone out there wants to become an eip editor it's definitely useful i'm finding myself getting burnt out and so and i don't want to put the eip editing situation back to where it was

before i showed up which was that eaps would sit open for like a year with no one touching them and we had a backlog of 500 or a thousand prs i want to avoid that but at the same time i have a lot of other things that i'm working on and the eap editing is probably the ones that i end up putting off the most and more and more lately they haven't put enough more and more and so so yeah so call out there to anyone who wants to become an ea editor please just start editing start providing feedback make a pr if if you want into uh the eap one i think right uh hi everyone there's the the file yeah

yeah that one yeah i think uh daniel raised his hand too yeah hi uh micah thanks for that call out and it's something that i'm thinking about i'm still uh very very new and i'm something that i'm curious about is the like what is the onboarding process for eip editors because i see there's kind of a note about the responsibilities of editors in eip1 at the bottom and you know i've seen that i've started coming to some of these meetings

um but i'm thinking about you know what is the formal onboarding uh process like because i think that clarity will help me figure out what i need to learn um to get up to speed and also provide clarity on um what it would actually entail so it's a very informal process basically show up on eips and review them for make sure they follow the rules in the ip1 and follow the template uh you can see if you if you want to go above and beyond you could go back and look through comments that i have put for example on other people's effects to get an idea of the

types of things i look for and the types of things that i follow i'm same thing with sam or light clients or any other editors just kind of if you wanted to look through see what other people are doing but yeah basically just comment on people's pull requests and say hey fix this this this and this um these things need to be changed et cetera the the job itself the day-to-day of the job is basically just making sure people's proposals are you know follow a general standardized format and style and so eips are consistent across each other um the kind of more philosophical side of it is um and this is

this is maybe just me uh so take this next part of the grain of salt before you continue mike i just want to say like i think the actual technical formal process for becoming an eip editor is making a pull request against that bots file yeah that's true so so the the bare minimum if you want to be an editor make a pull request against the boss file that being said generally we probably won't approve you unless we've seen you do some editing in advance so step one is going to build up a reputation within the either community which is very small as someone who is helpful and actually adds value and then step two is adding your name to the list and i'll send you a link

a pr and add your name to this that's that list or add your github handle to that list and then again assuming you have built up a minor reputation amongst editors as someone who has been helpful and useful then we'll approve and you'll now be an editor it's a very simple process um as far as like philosophy the one thing that i'm a little bit worried about and has probably the number one thing that has kept me from stepping down is that i really want the eip process to be incredibly neutral and this is starting to come up in some of the discussions that we're seeing but one of the ways that i worry and in the past we have lost this for a period of period of a couple of years

i don't want it to be an old boys club where if you happen to know some know the right people you get your ap has merged and if you don't know the right people you can't get your efts merged and so it was like this for a while where you know if you knew somebody like you knew one of the editors you could ping them out of band and say hey can you merge my eip and that set of people was also given a privileged position where they could just write whatever they wanted in the fb and no one questioned them so i want to make sure that the ap process remains as neutral as possible and as open to anyone who wants to contribute as possible so that means that someone comes in they submit a pr they're treated equally whether they're a core dev that's been around since the

beginning of ethereum or there's someone new into the ecosystem that just wants to help contribute and so that's the harder part of the job because it does entail you know telling some of the old guard no you need to follow the same rules as everybody else and it also does entail a lot of helping people who have no idea what they're doing learn to contribute meaningfully that's very helpful helpful make some contributions comment on things give people feedback i have

i have shared the link of a handbook that contains the information that is not available on eip1 but is a kind of rough process that is being followed around eip editing or um documenting an eip or even if needed for reviewing for the proposal so you may follow that and there is a section how we can onboard an apprentice to be formally added as an eip editor there you will find the link that micah has already shared in the chat here great thanks a lot i yeah i haven't seen this doc before i'll

take a close look at it and yeah appreciate the advice on on how to get started and kind of build a uh trust in the community and and a profile of someone who who might be a good um editor i see the the the path and and what it entails more clearly now thanks a lot and to be clear the bar is really low for building that trust uh basically just show up and be helpful and useful um you know for a extended period of time like someone we want to avoid as we've had in

the past people show up to help out with ending and they like help out for a week and then they disappear in every scene again and so we do want a little bit of a track record just someone who continues to show up and doesn't get burnt out after a week but beyond that there's no really no hard requirements it's just you know if you're helpful and useful and you're providing good feedback and even you mistake sometimes that's fine um just like as long as you're showing you know capacity to learn and and whatnot the bar really is pretty low sounds great yeah i'm um the the thing that intimidates me is my uh technical uh capability but it sounds like a lot

of the work is um doesn't even require that much uh technical knowledge it's just there there's a lot of um rules to edit the ipp so that they're just understandable to the community yeah the the technical knowledge isn't it's we generally want to have someone on the eap editors that is active and has deep technical knowledge um but not everybody needs to have that there is significant value someone can add without any technical knowledge just like you know basic grammar checking and formatting and style and you know making sure the rules are followed things like

that like things that you really you don't even like it's helpful to know what ethereum is but technically you don't need to rule so yeah don't feel um intimidated if you're not like an ethereum expert i think the the um we have a lot of ethereum experts as editors is because these are people who have tried to make changes to ethereum and gotten frustrated that there weren't the editors and so they joined uh it's not because editors need to be ethereum experts such as experts happen to be the class of people who generally stumbles into the eap process sounds great thanks yeah and uh i appreciate the the encouragement i will

uh give some of this a try hopefully and be uh be consistent about it thanks to you daniel and thank you micah um on the same topic i have one question for you maybe for micah and other ap editors um i see some of the pull requests are open on eipv github i'm wondering like um are we waiting on something or who needs to approve and get it merged i'm gonna share the link here uh eipv was most writ recently written by

matt and so matt would be an ideal person um yeah i mean ideally we'd have more people i don't actually know anyone other than that who would be qualified to did you mean to link something different no no actually my question is like now that eipv is moved from matt's personal repository to ethereum repository so i am assuming that now all i mean like obviously you and whoever has this accessibility as an admin for these repository may be able to merge it oh so so yeah so i don't know who has admin rights um is it just ethereum eipv

right i can check to see if i do um all right i'm checking to see if i have rights to edit stuff again sorry oh yeah i appear to be on some sort of team um that being said i know nothing about rust so i wouldn't usefully be able to merge anything or review anything i can click a button to to merge but we should

definitely have someone else actually read code and changes not me okay and for the eip bot um how comfortable you are for merging pull request over there um same thing the one difference is eap bot i actually see i know the language is written in um but i don't actually know anything about the bot itself ideally elita would approve and merge i don't know if she's still around though if we don't have anybody i can click the button but again it'd be good to get someone reviewing who is actually understands it in a perfect world for any code base you want at least two people and who get who are

both familiar with the code base um to so that way when one person submits change the other person can read it and confirm this is valuable if we don't have that um i can click the button but i can't commit to doing more than just clicking the button no i get it i was just trying to figure out the way how how we can move forward in absence of anyone being like key person who may or may not be around i know alita is still around she sometimes shows up in one of the meetings so maybe we can take help of her for now but i'm just trying to explore the best way in which we can manage this without you know

sure for the eipv changes so pr number 46 i can merge i can review and merge that one probably i'll re-review it and then for number 44. i think we're just basically waiting to get a general agreement but if alex and i are the only two participating then i can just merge it yeah i can handle these too the volume is small enough um but don't rely on me

for that in the future right but uh if uh okay how do people think about having these issues and pull requests even discussed in the eib ip meeting like you said that number 44 is waiting for general agreement i don't know it's been open since yeah we should talk about it yeah we should have more people here of course then i'll start adding it to the discussion items all right that's helpful i was curious how to manage these two depositories because they are not piling up with issues and we don't want to end up in a bad situation there all right

anything else on this topic okay if not then probably we can go ahead with the next item i see a comment from jose sooner than later bart would need additional coding to be merged that's right uh we are trying to figure out a way how to get these codes be merged all right moving on to the next item uh it is eap's insight monthly report nothing much has changed since the last meeting except we have got one

new erc category proposal added as draft the number is a eip4955 vendor-specific metadata extension for non-punchable tokens there is one small non-normative change to a funnel eip 721 other than that there is one eip which is in the last call and the last call is ending on 24th april the eip is eip 1967 standard proxy storage slots so people if you are listening and if you have any question comment concern related to this particular proposal

please reach out to the authors or participate in the discussion at discussion tool link this proposal will be marked uh final very soon because its last call is ending in next four days in this month um eip insight i have added the uh an additional chart to represent the different categories of eips since august 2021 because that's when they started collecting data individually so now we can see uh how many uh core erc networking and interface eips are being proposed as new eip and when they are merged i'm considering the data only if it is

merged if it is still in the open pull request form or the data will not be reflected here so that's one new thing and if people want to have different kind of data if looking for any other stats that can be added please let us know in either in the agenda item comment or reach out to me so that's all on eip status reporting the next item is eip editors apprenticeship meeting this week the meeting was postponed because of dev connect so we are going to have this meeting two weeks from now but a day before on tuesday

the last item for discussion today is uh looking into action items from the previous meeting just trying to pull out the notes here okay have ci update the creation date of an eip to the date it was first merged into the eip repo i remember having this discussion but i'm not sure if we did anything about it does anyone remember like what was needed here yeah which one was this uh 53.1 okay let me share the meeting notes so it is about um we discussed

about the mention of creation date of an eip and uh nothing i don't think anybody's done anything about that yeah right so i mean i'm just blanking on what was the action item if there was any do we need to create a issue in the eip bot uh yes the empire would be where this would go so that would be i think the next step yes would be to create an issue in the effort repo to automatically add the creation date when a new draft is merged yeah i'll do

that as part of splitting up issue 55 that would be great okay the next action is update the bot not to touch eip1 how is that gonna work i'm gonna do this again someone needs to do it if there's not an issue in the ap bot repo someone should create one actually there's this isn't the bot repo already i think okay i think i'm sorry please go ahead no no i just was just going to add that eip1 and i if i don't remember well

was any other living [Music] for every ip that was the company when they exact yeah eft one is the only living ib so something that's updated all living erps or aip1 both would work come okay excellent yeah that's true okay and the last one is update bought to have minimum two eip authors approval um before march specifically that should be added uh you should add the word eip1 to that so um right got it okay update bot to have minimum two eipod authors approval

before the merge of eip1 poll request right yeah really before immersion of ambiguous forecast i think we already have a uh uh issue out for this so that one that doesn't need to be an action item it's basically just need to wait for someone to write the code to do it okay there's no action right now we're just waiting for someone to write code okay okay maybe uh i will look into it and revisit this items next meeting hopefully it will be done closed

by the time but yeah we'll revisit it and i think that's all that concludes the meeting for today um anything else anyone would like to bring up for today's discussion nothing for me uh well we made quite good progress like but now we are at some clarity with executable specs and core eip process now we are looking into some general consensus maybe we be able to discuss it further in the next meeting

and look into the proper path for moving in the direction of pulling out core eips or leaving it in the same repository so maybe we'll have a decision not decision general consensus as i say uh in the next meeting so we made quite a good progress and uh yeah that's all i think i have to share with you guys today thank you everyone for joining see you all in two weeks thank you see you later thank you bye guys thank you bye