EIPIP Meeting 48

Transcript

all right uh welcome to eipip meeting 48. i just have shared agenda in chat the first item listed here is eip bot uh so as we know that there has been a lot of work going on on eip bot side um in the last meeting we discussed some of the uh working of different bots to be documented and i have also added some of the items which were picked from the discard discussions so let's start with the update if there are any on the working of different parts um would you like to take this one

very very very very quiet how is it now better okay a little better okay yeah uh i'm not sure i'm having trouble with my mic i guess um yeah so i identify that there are two boards basically one that uh a light line built built and then the other one was the the one that alita built uh as far as remember there is no third ball i guess uh so just a second can you hear me guys we can but there are some disturbances here you're cutting in and out like you have maybe an oscillating fan or something that's going in and out

is it fine now oh my god yeah give me give me one second i'll just swing one so i think we have two bots here for sure but i was wondering like there wasn't a third bot one i can see is like eip bot and other one is like uh which github action spot right yes we got the github action we got a bunch of bots there's like the greeter bot there's the merge bot there's the validator bot

and there's the old validator bot and i think there's one or two more so i think the greater bot is the same as github action bots i just read the name over there on the issues and pull requests that were mentioned earlier several of them use github actions but i believe they are separate things like dub actions is a kind of a tool suite and you can set up a number of different bots that utilize that and so the greeter is run by github action the merge bot is also run by github actions the validator is not it is run by travis ci

got it i think shashank is back i hope it's fine now maybe i should speak a little louder much better much better right yeah so i identified that there are two bots one written by matt and the other one was written by arita uh so i'm currently going through the bots i could i didn't get time because i didn't ha uh my health wasn't uh i kind of got covered and i got sick so i didn't get time to go through the entire court uh but i've been able to identify how the bots are being triggered exactly when they're being triggered so i've been kind of making a small note here and there so that i basically first understand what's exactly going on but like there are a couple of things uh as to

uh like how are these eip editors being assigned for for specific uh for specific reviews and like how the reviews are happening for each eips or the or the issues or uh you know uh pr's that are being submitted that i'm still trying to figure out um so uh that part so that that's that that's the part that i have a little bit of bottleneck to kind of understand like exactly how is that process being defined uh yeah so i can answer the question of how are you how are editors assigned um there's a file somewhere that just has a list of the different eip types so you have ercs and

core eips and informational eips and there's a file that says these are the editors it should be mentioned if it's uh erc these editors should mention if it's core eip i'm trying to find it right now i believe there it is so it is in this file um so that lines 19 through 26 i'm sorry uh 21 through 26. yeah it's easy recording okay make sense and then i don't know how the bot reads that but it's space is passed into the auto merge bot so like uh instead of

environment variables i think they get passed to the fee yeah basically yep yep so these are basically the usernames of the uh sorry github usernames of the individual eip editors as far as i understand yeah okay got it and and how is the review process happening like uh so let's say if i submit an eip uh which is like in pre-draft let's just call it pre-draft because not submitted so uh as soon as as soon as it's ready to merge or like being pushed into the eip repository like how is that process defend does the reviewer have to yeah sorry so as soon as you submit apr to the

repository the bot will see it and assuming the bot can figure out whether it's a query like assuming it's formed well enough that the bot can identify whether it's a query ip or an erc or whatever then the bot will mention the appropriate set of editors and then one of them will at their earliest convenience um review it give you feedback and then once everything's good then it will get auto merged or rather then the editor will approve the vr and then and after that it's directly uh uh it also it's being submitted on the eips dot ethereum dot uh the eips web

sub domain right yep got it got it so as soon as it's merged then it's basically every eip that's in the repository it shows up there uh minor exception i think yeah i don't know if we ever got rid of stagnant from the eifp site i think they still show up on the ap site but maybe they're not in the list or something okay and are there were there any edge cases in the past or were there any are there any specifics that have to be uh you know kind of remembered uh when working with the board especially regarding the eips uh there should so everything that's a problem with the bot should be filed in for the merge button at least we've had a lot of trouble elite has been working on it we keep trying different things

try to fix it and they keep having problems the eip bot repository should have a number of issues that is where we track like all the little problems like it could make sense yeah so ethereum eap bot and then if you look through the issues like only a few left so yeah i think a bug feature and i don't know yeah i think there's one persistent issue that uh we are having with greg i guess they get uh greg's username has been defined and i think that specific bug hasn't been you know reproduced again

so i'll keep an eye on it because i i haven't seen that bug being reproduced uh so basically that bug was i think uh micah you yourself pointed that out that greg was being showed as the first time contributor and uh so maybe that was the book i guess but i haven't seen that bug in the world again so but i'll keep an eye on it if you're into i've forgotten if you can find it send me a link yeah yeah yeah i think that was a long back issue and i am hoping that that must have been fixed by now because uh greg is already added an eip editor so possibly but

would not recognize him at least as a new contributor and that should not reappear oh yeah that one i think you'll need to fix that one yep yep yeah and other than that there are a couple of more open issues i have shared the link here in the chat so you know you can visit that and uh you can also look into the history of earlier box and those were fixed by alita and maybe it will help you understand what kind of issues are generally faced by these working of the bots yeah and for and for the validators so those issues are all related to the emerge bot um for the validator but there's a lot there's a number of things that i

manually review that could easily be validated like making sure the discussion to link goes to ethereum magicians and making sure that the eips that are dependencies of the iep in question are in the appropriate state to be dependencies you shouldn't have like a final eip should not depend on a draft eip and certainly that bot could very easily say hey this can't be merged until you move those other ones forward first um circular dependency is another one you can't have vip five dependent on four and four depend on five it's got to go one way um lots of little things like that so if someone has a desire to

work in rus then um the validator definitely has room for improvement um yeah i mean i have there is this one open issue that i like to pick it up because i couldn't find time over there because i got sick so i'll pick it up and also try to get into that part um so my current process to understand the bots and all the like anything that wherever any information that i can find i can find us reading the code understanding the amble file context as to why the specific merge happened or like you know like why this change was introduced so so that kind of helps but yeah it's kind of taking a bit of time

um but i like most of the like the core aspect of like how the workflow is happening and stuff like that that i kind of understand uh but uh like there are a couple of things that are still being done manually although the bot what was supposed to do provided that bot already had that like the auto merge sometimes doesn't happen like you have to uh close and reopen the issue to make it automatic or something like that so uh i might have to talk to elita once uh yeah elita has been fighting yeah elena has been fighting with the auto merge sometimes not working um for like three months we've tried like three or four different tools tool suites

um she's optimistic but i think also the same time as a good dose of reality behind her that the newest one kodiak will work more reliably so we'll see we just got that one set up all right make sense um other than that i think yeah other than that it's fine uh so hopefully by the end of the week i should have a bit of like a small document so that like anybody can who wants to pick up a eip issue can kind of understand like what's happening exactly at least the workflow part maybe not the entire details because it just takes a lot of context

to understand um thank you i think it's going to be a learning curve for everyone joining here for the first time because elita has actually contributed in building the bot so she has a better understanding of it and with some of the documentation and maybe looking into the process flow would be easier for new people to join in and start contributing more well i appreciate you working on documenting some of those stuff that could be very helpful thank you some of the next sub items that i have added here is like github action bots

grading pull requests uh it was mentioned by mike on the discord uh and i remember that in one of the eipab meeting we discussed we should have a greater bot for kind of letting people know who are creating the issue for for the first time even if it is not for the first time even if it is just for like you know um they they showed up and they are trying to create an issue on eip github and that is related to general eip discussion they should be uh moved to the fellowship of ethereum magician it looks like the fix that alita worked actually accidentally triggered for both pull requests and the

issues so that looks like a small fix and we might want to deactivate that just uh just close that that the greatest part get activated only for the issue section not for the pull request is my understanding correct micah that was the concern here that is what i thought we agreed to but i also forget anything so if that is not accurate someone please correct me based on this statement that the bot is reflecting it appears to be that way because it says that if this issue was created as a discussion too so that i mean i mean my understanding is it is

mostly for the issue section um definitely like to go back and check and if that is correct then we can just have a small fix here to get this deactivated so that workflow currently runs for both the issue and the pull request right but it has to be just for issues not for pull request um okay so what would be the reasoning for not having the creating message for the uh pull request like in gen yep sorry because that message uh simply states that if you are creating this discussion to uh this issue for discussion two for

an eip please create a thread for fellowship of a theory magician and that's just a simple one-liner message and it has nothing to do with the pull request um okay make sense more generally we don't have a problem with people incorrectly submitting full requests we do have a problem people incorrectly submitting issues does the bot actually catch that as like a a failed uh issue in the prs what do you mean like if somebody puts a link in the discussions to to a github issue does it flag it doesn't involve no no that is something that would be great if someone wants to take up uh if you if you love rust

and the elevator bot is written in rust and could should be an easy thing to add so by validator bot you mean the one that is run by match right now like the eipv or is it a different one i don't know who runs it it is was written by the most recent version of it was written by matt you know who runs it what i meant by that like these issues we can probably go and create issues over there and then start sharing the link for people to come forward and work on those issues i just wanted to make sure where do we want to create these issues validations page i would assume would go

on the eip validator repository and things with the auto merger and the greeter and things everything else should probably go in the ip repository at some point in the future it would be nice perhaps if those were consolidated um but at least for now that seems to make more sense that make a lot of sense all right so uh moving on uh the last item here was issue with the auto merger bar i i i suppose alita is looking for any alternate proposal and as mike also mentioned earlier that if someone has any suggestion merger bot is something that people are struggling with if you can help with that

please reach out to us anyone on the discord the ap editors or the canada's team the next item here is the state of execution specs and an introduction to the core proposal for an introduction to the proposal for core eip standardization process so as we know that this is not a new item for the eipab meeting as the execution specs repository itself is the result of a discussion in the past eipib meetings at presenter the cool team is working on documenting specs for execution clients i suppose in python and

the cat had always wanted to support the work and communicate it to the rest of the community so we hope to have sam wilson talking about the updates and also based on the progress maybe we can start discussing an alternate approach for the standardization of core eips so sam if you would like to speak sure put it um how's my audio is it all right i'm using a different headset today perfect okay cool sound as beautiful as always back into compliments um all right so uh i don't know where you guys are like how how closely everybody's been following the execution specs but it's basically just a python reimplementation of the yellow paper

um peter and boith have just put up the pr for uh spurious dragon so we're slowly but surely catching up to mainnet um yeah i mean the documentation tools are pretty neat you can go take a look at them i'm not sure what kind of an update you're looking for in the actual progress um but yeah we're getting there um as for the actual proposal for how we're going to do eips in the future um there is the peeping video that probably goes over most of it the short form is i'd like to replace the specifications section for core eips with a diff into the execution specs repository and then

we can collect all of the eips as uh like markdown files inside that repository and that way we one kind of get to separate ercs from eips which i think mica would probably appreciate and uh and we also get like a bit of documentation that goes along with each code change in the same repository and i think that's going to make it a lot nicer for uh for following along when you're implementing a client thank you um with the updates i was just like wondering like we should keep people uh updated on how far along we are as you mentioned that spurious dragon uh protocols are

already up that's really good progress we have a few more upgrades to catch up to just a few yeah not that so that is nice to know and um about this uh the new proposal uh i have shared the link in the chat for people who may have missed it but it would be interesting to hear more thoughts on it i know micah and many other are very much interested into having a separate process so it would be interesting to learn about what are the prep work that we can do like cataracts can support with to just bring this proposal to the community and maybe actually help out and

uh using this for not for the merge of course after merge whatever if it is shanghai or whatever it is if if there is any thought on that i mean i think coming up with how we want eips to look like when they're incorporated into that repository would be a great step like uh and also there's like portable underground well you just don't want any english description whatsoever you just want python that's right english language has been failing for the last 40 years i'm done with it all right all right we'll migrate off that uh if you're a lodge band fan then we we can use that um okay but yeah so i think uh yeah that would

be a great start just playing around with ideas for how we want eaps to look and what kind of structure we want for them um obviously thinking about how the bots are going to have to change to enforce whatever constraints we want on the new repository um yeah and and obviously just like socializing the idea of changing where we look for eips um and maybe getting feedback from core devs on you know do they think it's useful do they think cause like i think we're far enough along in the specs project that you can look at and be like this is a good idea or this is not useful as a core dev and i think we should start getting that kind of feedback as soon as we can um yeah those are kind of my thoughts if someone wanted to let's say we live

in the future and all we have is the specs repo and someone heard about eip i don't know 151 or something and they wanted to go look it up what would that look like and specifically choosing an eip that is in the past like something that currently is the oldie type vip do we have any ideas of how we might be able to port those over somehow so it makes sense for someone to i think the uh the goal sorry i just uh had a contractor come into my room um so i i think the goal would be to have all of the old eips ported into the same format as the the new eips um

for core eip specifically right yeah exactly yeah erc is you you really can't represent in the same repository so yeah and so what did what do you imagine that would look like in your perfect world okay so i think the way i'd want it organized is um so it's hard to separate an eip out from the fork it was in um but i think you should be able to get a decent idea from the diff between the fork and the previous fork which we generate and the the text document that describes the changes um and that's probably how we're gonna have to do it okay so you're thinking that along with

each fork there will be a text document that will describe the changes and those text documents would each eip would have its own text document and then each text document would have to describe what fork it belongs to i see so you would have uh like any ipv5151 uh document that described the change and then would link to the diff where the change was included for the actual specification part so that'll be a lot easier in future eips and we have the process formalized but for older ones i think it's just going to have to be like all of the eips in a four in one diff because it's hard to maintain individual gifts per eip yeah

like even maintaining gifts per fork is is proved to be challenging but yeah okay yeah i can actually show you i think what one of those looks like give me one sec execution specs and we want something in tangerine whistle what what wasn't tangerine whistle that was the uh dos protection if i remember correctly right no idea come on you guys are supposed to be experts on this i'm a noob i don't know anything before london yeah

before berlin nothing before berlin for me so i'll put this in the chat here so uh this is or actually i could just share my screen that's even better yeah i cannot share my screen so i'm sorry just give me a just give me a second let me chat oh it's not your fault it's mine i'm i'm in wayland so i can't share my screen with zoom um but yeah so you can actually take a look at like what those changes look like in the rendered documents and this is something we're working on you know improving and making more readable but i think it's coming along nicely so if i understand correctly the idea

here is to have all the uh earlier eips that went into one of the uh earlier folks to be documented in one days and for the upcoming eips which are to be considered for upgrade they will have their separatists and they in that uh other than the um the specs there will be a separate txt file which will contain other information whether or not they go into the upgrade like uh it is a separate thing but we will have one uh text document for every proposal that is being proposed for upcoming upgrades exactly yeah and then like i i kind of imagine the way it'll be developed for an upcoming fork will be

every every eip will be developed in its own branch and then we'll be generating the documentation from all of those branches merged so you can kind of see what the next hard fork is going to look like but then when the actual uh the actual hard fork is is decided and made all of those things will be merged and you'll be able to link to each commit where those eips were merged sound interesting and it will be more interesting to actually get this implemented i understand like we are at the very early stages but having this discussion at least giving up a high level picture of what is being imagined here maybe in the upcoming meetings we can

try to have something documented and then think more about it and then see how it comes up to be yeah that sounds sounds about right thank you thank you for that update and yeah anyone has any question comment before we move on to the next one if not we'll try to keep this item like if not in every meeting maybe in alternate meetings to at least kind of reviving this so people should be aware of this this new process and

the process that is being proposed even if it is not finalized we can start collecting feedbacks and discuss feedbacks in these meetings to kind of formalize the process moving on uh the next item is a eip's insight that's a monthly eip status reporting update since the last update there is one new proposal added in the past two weeks and now we have a total of four new eips in draft status and um there are three eips in the review status eap 4200 eip eip4626 and eip3668 obviously

eip3668 is a no more in review but it is listed here in review status because it changed its status in the month of january itself for uh that particular proposal that has now completed its last call and we should be expecting a pull request to move it to the final status very soon by the author uh the last call period for um three of the proposals which were earlier in the last call is now over so ideally all the proposals are eligible to be moved to the final status 366 is one of them and the other two proposals are eip3448 and eip3607

there is one additional proposal which is resurrected from the stagnant to review and the number is eip2980 that is swiss compliant asset token and there was already one proposal which were resurrected from the stagnant status technically we have like more than uh three we should have five in the review status but again one one has uh completed the last call so only four left in the review status there are four proposals which moved to stagnant because of part they they were inactive and there were a few minor edits to the final proposal please check out the eaps inside for january to learn

more about the eips activities yeah uh i see the comment from micah and it is really good these updates from sam give give everyone not only micah hope for brighter future for a reason not to just live just to be a part of this community as well thank you sam moving on the next item listed here is eip editor apprenticeship meeting we had this meeting yesterday uh there were reviews on some of the pull requests which were submitted over the past two weeks the highlight of the meetings uh

including some of the pull requests those were discussed uh yesterday are added to the summary section which is available in the comment to add the agenda to the meeting um we can expect at least one more proposal moving to the final status that is eip 1271 it's it's an old proposal and it's a big win for the team because this was a long due proposal to be moved into the final status there were some edits and recommendation to other pulled requests um one of those were eip2982 which is an informational eip for a serenity phase zero um please check out the video and the

summary linked in the eipip meeting agenda for the details of the discussion happened in the eip editors apprenticeship meeting and this meeting is bi-weekly so we would be expecting the next one two weeks on tuesday that's mostly what we're listed here on the agenda and the last item is review action items from the previous meeting so from the previous meeting as we can see there are only two uh shashank will be working on documenting the eip bot improvement uh he is already working and we should be having something added to the maybe readme file or in the dark

for new people to contribute to and um i did check with william in trichen and uh unfortunately i did not receive any response yet but for some of the questions those were asked in the earlier meeting uh if we get any response we'll try to add them in the upcoming meeting to address them of course and i'm also talking to um ef devops team to finish the migration it is still not done for the eipv that we are discussing from past few meetings um i will check back with the team one more time and let's see we hope to have this migration done to the ethereum

github repository i hope by the next meeting i don't know yet i'm just waiting on the response so that's all anyone has anything to bring up these eipip meetings seems to be a little shorter but i think we are trying to cover the bases on whatever is going on and if anyone has any question concern related to the process and they would like to be addressed so if you are one and you want to contribute or if you have questions please leave a comment to the agenda so we can pick it up and we can

bring it to the next meeting well thank you everyone for your time hope to see you guys around in two weeks we'll try to be on the same call have a good one everyone thanks puja and everyone thank you bye-bye thank you