EIPIP Meeting 49

Transcript

welcome to eipip meeting 49 i'm going to share agenda here in the chat for people who may have missed it the first item listed here is about eip bar but i don't see any team joining in so far so we'll come back to that item and because we have a lighty here let's go ahead and pick up his proposal that is item number three resurrect eip 1328 so we came across this eip in a peep and eat meeting uh for eap 4361 sign in with ethereum do we

realize it is not required for ethereum sign-in proposal but uh is an important one for other projects um i had a chat with liggy last week to resurrect this proposal and he had some questions around that the process changed that happened since the proposal was documented so yeah um over to you like if you have any question and i would like to share with the ap editors yeah it was basically about the new items but we just filled it out with uh pedro now so to just like fulfill this new um property so basically i think we should have filled everything

um [Music] should i fill all the changes yeah so everything exit was saying was missing and also added for the new um 2.0 standard basically there was a little bit of change there yeah want to work a little bit more the security considerations there's a little bit missing um i just talked to peter before because but he couldn't make it to this call but afterwards we hope it's uh merchable so yeah because it's used uh it's widely used and we kind of want to make it final saw the path to find it so make it draft first

and then wait two weeks and then make it final so going by the earlier comments on this uh will request it looks like it is okay um i have added the link to the agenda so if there is anything that is needed from uh editor's point of view um please leave a comment just wanted to bring it to attention that we would like to direct us yeah thank you for that i hope we can get it alive again all right thank you moving on uh the item number two here is what to put in the test cases section

um so this is inspired by mikhail's comment which is there on the discord ether and it is called but i suppose it will be useful for other authors as well um is there a general guideline for adding test cases section so by general guideline i mean can it be updated in later statuses for example eap 3675 that is moving to review so is it okay to add a test plan or the link to the test plan and when uh the testing is done before moving it to last call that will be updated so the test cases section test cases section is optional and uh part of the reason for that is so

people don't have to make sure have test cases ready at the beginning um so whenever you have desk cases ready add them in if you don't have them then just leave the section out entirely so by optional it means uh for proposals so i'm sure it it will not be the core proposal but any other proposal if they do not have test cases just the reference implementation should be working right there should not be a blocker oh yeah reference implication implementation is also optional so if either the sections are missing the eip you can still go through the full process and we recommend them like it's it definitely helps to have good test cases and reference implementation but they're

not required cool all right that is good to know um we will update the author i i think that was it on this particular item i see shashank joining the call so i i suppose we can pick up the item of the eip bot coming back to item number one following the working of the bots in the past few months we all know that automation has helped us a lot and i was discussing to some other others and they mentioned that it has helped us and like moving things faster

comments on github and ethernet discord shows that there are still room for improvement we are making progress of course so to continue these um improvements i have added this as recurring item for eipip meeting uh the first sub item is the progress on documenting working of different bots i know we discussed in past few meetings from shashank if you may have for that update on this to share yeah yeah so i discussed with alita on the on on our research or discord and i realized that while i was working on the documentation all the documentation that was actually necessary was already present and any of the rest of the flow that was required to understand as

as how these bots are working that specific part is already present in the yaml files in the configuration files and any of the doubts that i had was cleared by micah in the last meeting i guess last last meeting so i'm i'm uh now i'm failing to understand if we should even continue working on the bot documentation because i don't feel it's necessary anymore because major of the confusion that i had was understanding where it's starting and where it's ending but if you just see the documentation and go through the code it's actually pretty much self-explanatory if i can say good to know um we just wanted to make sure people who are trying to join here or finding ways to contribute as a new contributor

should be able to find that now that we are sure that everything is already there and should be easy it's good to know we are currently collecting issues on eip part github repository so if there is anything related to eip bot that people find is not working please add an issue on the eib bot uh github the link is added to the agenda uh related to bart i had couple of couple of items to be discussed by attempts actually uh there is this tag ambiguous uh i'm wondering like uh what is the logic

behind that like uh how do uh bart decide that it needs to go ambiguous and not new or anything else are we aware of yeah i believe ambiguous is the label it gives when it can't tell what type of vip it is so uh normally the bot i think will label things as like an erc or a query ap et cetera if for some reason the bots i'm able to figure that out usually because the header data is incorrect i think that's when it labels it ambiguous and basically this means some editor needs to look at it and give feedback to the user to tell them what to fix their problem basically so sh error is in the header data right probably i i think so

you have an example of one that smart flags ambiguous i think there was one that we came across yesterday that was a new proposal but we were not able to figure out why bot marked it as ambiguous instead of a new proposal i'm trying to pull out let me take a look i can find one okay i'll try to point it out so my guess is it might have gotten confused because there's two files in this pr i thought the bot handled that but maybe on new eips it struggles with that still that's my initial guess

that makes sense having two file number can create ambiguity there oh yeah that makes sense i thought the issue was there was no eip number in it yet and so it probably just departs the preamble no i mean you can it'll it'll parse the preamble without the ap number i believe wouldn't it and also his sense it should be able to that doesn't mean it does though uh yeah okay so look looking at the bot message it did parse the eip itself but then it failed to parse the the image oh i think i see we're saying okay yeah so the image was put into the folder eip

dash xx not eip-4780 and so the bot is confused what this file is because it's not in a folder that it recognizes so yeah i like clients right so is it that it's not about the eip itself but the placement of the file right is that it yeah so if you look at the conversation on eip 4780 and you look at the bot message it has two little sections there one where it has details about ea p4780.md and the other one about the asset file and it got the ambiguous classification from the asset file yeah the resolution it has and you can see that the file name is asset slash eap

dash xx that should be assets slash eap dash 4780 yeah and it happened in the auto merge board of fail check yeah so as soon as the user fixes that it should record i i think the bar should resolve yeah the reason why i was stuck to it because my initial thought process was if a proposal is new we should not be expecting eip number over there so it should ideally be categorized as new proposal instead of ambiguous so i think at least right now it is classified as a new eip it's just also ambiguous because it has a second file that it doesn't understand

yeah so once once the second file is understood then it should be just new that makes sense so that's a very good use of labels and i also find the usage of a new label called editor needs to review yesterday we were discussing how we can um like make it easier for eip editors to figure out which new which proposals or pull request needs review uh this is basically for uh the new reviewers who are trying to join uh the group and maybe uh help with uh looking into some of the proposals wondering if we have all already set

logic for editors need to review or is it being manually added i believe it's manual at the moment um i think uh so i'm checking on eip 4671 non-tradable um not readable token by omar flack and in the board it shows that this pr requires review from one of light client and a basic and that's it uh me and i'm not sure if the label was they will happen because of that is that it or i think that's a little bit different than what we want right because that's saying like we need a like permissioned editor to come along and do like a something that requires

authentication like merging or something on those lines which i think what we actually want is more like a label that says um hey somebody has looked at this and they have like tagged the bot to say now we're waiting for the author and then the author can reply or push a commit and then it just flips back to like an editor mode yeah so that one i added the tag for and i don't know why but that actually helped micah because i think if this is a tag which is available probably we can look into automation of it and how to make best use of the stack so what would be the case where this tag

would exactly go like how how would you suggest which part does the bot identify says okay this is the part that it's not matching the spec maybe and it needs this label called the editor needs to review so i would say it needs edit internet review ideally would show up automatically when the eip is passing all ci and it is a status change or its new ap so basically when it's at a state where editor needs to review it and the user has already resolved the ci issues and and if it hasn't if it doesn't meet those criteria it needs a waiting for author tag i think uh yeah like if we're gonna do about

have the bots use labels like this then it would be reasonable to have an inverse tag for awaiting author something so i think here is like in general cases whenever it is like status change or what is passing other ci and other checks there is this label um status change that can help editor to know that okay fine this is done but there is one specific case where editor is not able to identify whether it is up to him or up to the author for example when a label is added by an editor

requires author's response even if author respond to that a comment that label is not going off and it is not changing to a back to editor needs review i think this could be a good use case where we can make use of this label yeah having bots do the labels automatically is nice because like you said they will go away when you're done with them whereas a human brain label on thing probably won't remember to remove it later yeah because that takes the pressure off of the ipa editors and also authors right um you can save a lot of time instead of

manually attacking each of these uh air protectors maybe i can create an issue on the eip bot github i'll will try to figure out how to make best use of these labels i mean particularly editor needs review but is there anything else sam and likeland you would like to add from yesterday's discussion um i i get one point where the author is unable to remove the tag of author has already reviewed it and would be good to have editor's response tag over there no i i don't have anything else to add

there all right maybe we can start with that um we'll see if if we can try if we can automate that response and maybe make use of this tag okay that's on the eip part so we already have covered number two and number three number four this uh topic was added by william and triken so a few weeks ago we discussed some of the comments left by william treiken in the eibap meeting and based on the recommendation he created

this pull request to update the readme file and um i invited him to add today's meeting i don't see him here so probably we can skip the item but i have added the link to the pull request that he add he created for mission statement in readme file looks simple and i suppose it has already been approved by one or two editor there so if there is anything any change is recommended feel free to leave a comment and maybe we'll try to bring this item in the next meeting when he is around item number five is about execution

specs so we discussed it in the last meeting and i remember sam wilson also talking about an all core dev meeting last friday i'm not sure if there is anything new to add but if not this is just from the last meeting sam sorry i missed it i have added it since the last meeting we discussed about it and i know that you have already shared update in the all core dev meeting last friday so just wondering if there is anything new to add if not we can move on oh no no no no no no not a problem yeah please it would it would be nice if uh the execution spec people i.e sam and peter i think

and the eip editor people could come to the table and come to some sort of agreement on what we think the future of eips is i think if we can present a united front to the core devs we'll go a lot smoother than if uh the execution spec people and the eip people are bickering while also trying to get feedback from those i definitely agree with you there i don't know when the right time for that is but um when i would say before you want to start to bring up with the core devs a change in process we should probably have one or more discussions oh for sure yeah i'd like to have like the

actual process documented before like like actually in like a text file before we uh bring it up yeah i just want to make sure that we don't like jump the gun and core dev starts giving input um which is going to be a uh a lot of bike shedding i suspect this would be nice if we had you know this is the bike shed you're gonna get this is the color it's gonna be deal with it um is there anything that uh you know we don't agree on so far from the bag presentations i've given i think the only thing that i don't agree on is keeping the eip process as it is like i

would i would rather see things move more to something new like i feel like this is a good opportunity to break from the old particularly for corey aps for year season whatever we can be separate but i think this is a excellent opportunity to break away core eips into their own new thing that is separate from everything else yeah i think i think we do agree on that i'd still like to get into all the eps though um i mean you could probably convince me on that i i weakly want to get rid of the name just because the name brings with it history and i'd rather not bring the history but um that's not something that i will not heal out without dion and i'll die in a lot of hills

michael could you give an example as to how these korea speaks can be broken further um you mean how can we move them out into the execution spec stuff yeah just an example um like in my perfect world of rainbows unicorns that will never exist we would have uh as people are doing pull requests for the execution spec we would document in there um somewhere the like the human readable version of the change control process it would not be over in the aps repository it would not be a separate document it would be somehow

integrated with execution specs um and and or the pull requests to them so that way when you're looking at a diff you can see the human readable version along with the diff in some way so i think the only um concern with that is it would be very so so we can do um a diff per hard fork fairly easily well i mean it's not fairly easy but that is the the path we're going down but if we want to maintain a diff per eip um that would probably be a lot more work so i i do not feel a strong need to keep a diff per eip but i suspect there will

be people who demand that and so having in particular i think people want the ability to point at a change set and give it a name slash number slash identifier of some kind and i think that's gonna be the hardest thing to fulfill yeah i mean so that's pretty easy when you have um like like during the development process for an eip but once it become like once we're done and we're moved on to the next hard fork um every change set that we want is we like has to be maintained so like right as a good example of this yeah so um as a good example this eliminating the

accountants to [Music] two to the 64. um like that chain like for every diff that we maintain we have to backport that change to it so if we have more like if we track each eip separately then we have to back port every like kind of refactoring every uh soft fork yeah and it gets really tedious yeah so i i'm with you um and this is part of why i think that we should all agree before we go to the core devs um so that way there's a better chance we can fight for these things that are kind of bigger and are going to be more contentious such as dropping the permanency of unique identifiers for changes i think we can still have those it's

just like the active hard fork you'll be able to get a diff per eip and then for past hard forks you'll only get like a rolled up diff for all the ieps and that hard fork and i think that's probably the best we can do and that rolled up diff would also like wherever we're storing the human readable version of these changes um that would also be rolled up with hard forks yeah exactly yeah you'd get all the motivation here's all the everything yeah right yes i think that that's the one piece that i suspect we're gonna get some pushback on i like it and i'm with you on it i just suspect there will be people that strongly want to have like the ability to link to

you know eip1559 or whatever and have that be a kind of permanent link that lives forever and is isolated to just that change not all other changes in the same hard fork um i agree with you i don't i don't want that like because i think that it's gonna be complicated things too much but i do think there are going to be people that are going to lobby for that pretty hard i mean compared to it's unfortunate for them but it's impossible so you can answer that's nice you can't have it yep i mean if they want to you know give me 12 developers full-time that literally go through and you know my newly changed deaths sure but i i don't like me and my three

volunteers can't do that right yeah okay and uh i think we're on the same page then okay good i have to hop off to my sink call so i will talk to you all soon thank you for joining sam well that was the idea i totally agree to uh micah and sam uh we wanted to have this process well explained here in these calls and when we have something real solid we can go back to the all all coder meeting presented so people be on board and that would be the time of getting feedback from them if there are some small changes requested i talked to one of the cat herders who is trying to contribute on

the execution spec right now he is also trying to kind of put something together maybe in form of document representation with the help of sam and peter and we hope to see some updates coming soon on this front okay anything else all right moving to the next item it is a eip insight for the month of february uh in february we have received two new drafts eip four seven five zero eip four five two seven four seven five zero is

eof functions and four five two seven is qr data transmission protocol for the offline valid there is this one proposal which is in the last call eip2098 so uh this proposal uh two zero nine eight it is compact signature representation it's an informational um type proposal uh we had a chat with the author for uh peep and eep for this particular proposal and it appeared to us like this proposal should not be informational but it can be an erc and both the co-authors um richard moore and nick johnson are in agreement that it

should be moved to the erc category i wanted to bring it to this this discussion today because the last call period is ending on february 13th and if we have to make any changes it has to be done like sooner rather than later so any thought from any editor here sorry which number you say eip2098 it's it seems like an erc but presently listed as informational eap um

that can go either way i generally don't like your uh informationals at all like i like them just not exist so i have a weak preference for erc on this one um yeah because this is like in the last call and is almost ready to final uh we thought that we should discuss it with eap editors because authors are in agreement and we hope to see a pull request soon requesting for a type change yeah i think i would accept i mean i don't handle erc's or informational so it'll be up to matt and alex ultimately but i don't see a problem with it

sounds good unfortunately uh matt has to go so he is not in the call but we'll bring it up later on with him maybe when the pull request is available and uh for other proposals um this month okay there is one more thing that i might want to check with you micah you may be able to help me here it is eip 663 so in the um eap inside i'm going to share the link right here um what happened like exec created this pull request to maybe update it something went wrong and then it was reverted and then new pull

request was created so i'm wondering like first of all like why did it happen uh in the first place because exec is both author and the editor it should be fine and um if you have any insight on this particular issue so i'm not familiar with the issue referring to but an editor should not be able to merge their own eips they should be requires a second editor to review them so like alex is an author he needs me or matt or greg to emerge yeah i just have shared the pull request number 4752

is the one when it was resurrected i believe and the other one was again let me get it for you four seven four nine it is so i didn't understand the reason why it is there but um both showed them as much and now there is this new pull request so i was wondering like why do we need to have a new pull request and why is it not getting auto merge i'm also sharing the question yes okay so the first one um 4749 was alex submitted full request to change the status from stagnant to draft

because he's the the author it should be waiting for an approval from an editor before it emerges but it appears that um it looks like elita said she drastic oh okay so it looks like it was a bug in the bot and lolita has a bot a ticket open to uh get it fixed i guess yeah i think i i got the problem right now i mean like as you mentioned that because it was uh

because exec was author and he was trying to resurrect the proposal that's maybe the reason it is waiting because i was wondering like the new pull request number four seven five four why is it still waiting i got it thank you so much um uh yeah i think that's all on the eip inside i have added a new dashboard this month uh that is for the proposals uh that are added as draft versus proposals that actually moves to final um it will be interesting to see it like very few proposals are getting to uh final status in comparison to proposals

which are added as draft which is normal of course but yeah i'm excited to uh look into these numbers that's about eip inside and eip editor apprenticeship meeting is the next item we had this meeting yesterday i have added the recording and summary for people to refer to um it is again the simple process where uh eap edit is explained to the new people new contributors who want to be reviewers so it would be it would be a good learning although we had some hiccups yesterday internet was broken but yeah people can go back

and refer to the next meeting is planned in two weeks from yesterday the last item for today's meeting is a review action item from the previous meeting i have added a link here i suppose and action items were checked to make sure the greeter bot gets activated only for issues section not for the pull request i haven't seen any new uh comment from creator but by any chance anyone else has observed maybe we can revisit it and look into it

i am hoping that this issue has been resolved anyone with suggestion about the murder bot should reach out to the eip editors or the cat holders team i haven't received any new requests but this is still open if anyone has an interest or capabilities to look into the merger bot please reach us 48.3 includes furious dragon update in every alternate meeting we did talk a little bit about the execution specs today we hope to see more updates in upcoming meetings uh that concludes the item those are listed here but there is one thing that i wanted to

maybe bring up today um i see there are three new issues created for three respective eips i suppose this would be a good time if we can ask the author to move to the fvm portal for having a discussion tool link um micah i remember yeah i remember there was some concern in the last meeting about the updating window that was allowed for updating at fellowship of ethereum magician

um yep has it been resolved i'm not not that i'm aware of i will check with the team uh but i mean i know that this is uh from like a free software that was mentioned by uh greg in one of the meeting earlier so i will check with the team if this is still the case or people can update it but if there is some something like someone is looking for some immediate help we can probably get it updated from back end yeah it's the the one thing that i'm waiting for before i really start pushing hard on people to move over is that because greg did bring up a good point that if you can't

um repeatedly edit indefinitely your original post then it doesn't serve as a complete replacement for github issues so as long as we are unable to edit marginal posts i think that we will have a hard time asserting to people that they need to move that make total sense i don't know a liggy are you part of that team uh the fellowship of ethereum magician sorry to put you on the spot i'm just wondering like who would be the best person to reach i know uh anna and uh maybe jimmy but anyone else who are aware of the process behind the scene for fellowship of a theater magician they seem to be stepped away from the

microphone maybe for a while but i'll check with the team and we'll try to have some update by the next meeting and yes one item that i already have shared in the discord channel that now the eipv the eip validator that has been moved to ethereum github repository so that's one good thing that we achieved in a while and that also concludes the item listed here anyone else has anything to bring up uh we should probably uh discuss not many more people in the call but we should probably discuss making um sam and or

um who is it will um editors tried quite a bit of editing lately that's right yep uh yeah i did chat with the light client on this in one of the meetings maybe earlier i don't remember when um and we agreed on your suggestion when you recommended that people who feel like being an editor uh should come forward and say that they have been continuously making contribution as you mentioned that we don't have most of the people around do you want me to add it in the next meeting as gender item we can probably have a discussion on this sure all right yeah that's a very good point

now that william and samuelson are there we can probably have them write accesses and it will be helpful to make things moving faster okay and um there is one last issue that i can find it on the eap github that is related to proposal 4337 i don't know if anyone looked into it or not the number is 4783 maybe any editor can look into it and leave some comment these are just some uh typos changes must should not but i'm understanding if

they are under a special bracket there should be a reason behind it let's see which one 4783 pull request number is 4783 and the changes are suggested for eip 4337 oh uh yeah this is this is not any uh pr this is just a an issue um so someone can just comment to on the issue and just tell the user please submit a pr yeah i was just trying to verify here are these like valid corrections or

or maybe we can tab author here to jump in right yeah so when you create when the person creates an eip to make these changes or sorry when this person creates a pr to make changes the author will automatically be tagged okay and then the general recommendation would be like maybe we can comment on this issue uh asking the person to maybe create a pull request to uh such as these changes to the proposal yeah this still it might be that the user doesn't know how to create a pull request and so you might just need to walk them through the process okay okay we can look into it

all right that sounds good and i think it has concluded everything anything else anyone would like to bring up today well in that case thank you so much for time uh and thank you so much for joining and i'm gonna create the agenda for the next meeting right after this meeting please feel free to add your items that you would like to be discussed in upcoming meetings with the eip editors obviously it will have the regular items but it would be good to hear more issues that people would like to be resolved that is related to eip process or any particular proposal

thank you everyone for joining us today have a good one everyone