EIPIP Meeting 38

Transcript

welcome to eipab meeting 38 agenda shared in the chat the first item on the agenda is evolving eip process i have added it uh considering we discussed uh like in bits and pieces in past meetings so now we have a consensus specification i think some work are being put in by the quilt team and with respect to much do we see any any changes in the core eap process in general so just wanted to bring it up um maybe um matt if you would like to add some yeah add some thought on how we can improve it um really quick before we get started um if tim has to leave

early do we is there anything we want to move to the front of the list to make sure we get his feedback on in my opinion yes first uh the this item like corey id processor will be changed so that is something we can use okay i guess maybe a way to make this very concrete um do we think that the eth one spec will be ready for us to use it like as the merge spec so mikal has an eip out right now um like do we think uh yeah that's what like basically are

we gonna start using the consensus spec after the merge or do we think we can actually use that the specter merge and possibly move over mikael's eep um as part of that or you know alongside that yeah if this was like in more of a normal fork i might say yeah but i think because the merge is so complicated where we also have this pretty mistake thing i would say let's like plan to not worry about it okay and we'll see the speed at which we finish the spec and if it happens in the next couple months and we talk with danny and we're able to get to inter-operate with

their spec then maybe it makes sense okay i think because of how complicated the merger is going to be it might just cause us more pain got it and one one option is also say we get to like the merge test nets with the eip you know we can then almost like backfill it into the spec right um so maybe it's not maybe it's not what we use to implement the merge but maybe it's kind of ready by the time the merge hits maintenance um where there might be like several months lag yeah that would be a pretty good outcome i think for the spec all right so if i understand correct we

we may be expecting some changes in the process in terms of like we may not be going by the eip process in general uh like uh not for the entire set of uh the proposal just for this pack part we can manage it with the help of pull request and rest of the details can be added to the eip just like we have 36.75 yeah and we should keep assuming 3675 is what we're gonna use like and share the clients and iterate on uh over the next couple of months oh that's great all right all right that's about core eip um i'm not sure if we have any more

clarity at this point of time uh yeah if anyone would like to add anything otherwise we can move on to the interface one okay similar to core eib i know there are some work are even being put in for the interface eip we did discuss yesterday with uh within the meeting that eip editors training meeting uh in general how do we see interface vip in future right right now uh i see quite a lot eip which are in draft status and review we just have like a handful of i think seven or eight eips as finance so do we want to keep

interface eips as it is or we do have to deprecate that in future i feel like we can just keep them as they are and just have the understanding that there will be no more rpc eips with that means uh whatever is interact and review they did not need to move forward and we can just uh move them to withdrawn status or uh just leave it as it is i don't know um it'd be nice to clean them up eventually

i assume the rpc ips are probably final at this point i don't know where are they specific yeah there's there's a mix okay yeah just share the link in chat can i just delete them yeah that's what i'm wondering like if these proposals if we are assuming that they they're not supposed to move forward to any further status let's move it to withdrawn and we'll make a statement like we have other banners for uh

different proposals we can have a banner for this particular category written here that these proposals are not supposed to move any further and we can be using the specs repository for any anymore interface eaps that make sense sure yeah i think it does i mean a lot of them are yeah yeah yeah yeah like there's a bunch of weird ones and yeah okay in that case i will create an issue to look for someone who can at least first the first thing first create a banner that we are not moving the status of interface eips and we should be using the spec repository for any further

eips in this category and then eventually i'll try to reach out to different authors and create pull requests to move these proposals into withdrawn status so there are a few interface eips that are not actually json rpc so i think the category still needs to stay until we find a home for the rest of them yeah there's a bunch of weird things there's like stratum uh renaming up codes like i don't know what wallet permission system is um yeah so like there's a subset it's json rpc

stuff that can be removed or marked as abandoned or withdrawn or stagnant or whatever um but there will still be an interface category and there will still be eips in it which means we can't just blanket put a banner on i don't think or if we do we need to make sure it's very clear that the banner only applies to json rpc which is yeah because there's stuff like that you know the trace specification like there's a bunch of yeah i guess they are interface eaps yeah okay in that case it looks like first we need to uh like separate the eips which are non-json rpc eips and then uh the withdrawn stage

status could be applied for only those are json rpc specific eips and for rest of it um we can just have a banner that no more json rpc eaps are uh like can be found here or unusable here that has to be used with the specs depository and for rest of the interface eips this is good to go um i'm not very sure like how i mean i am a particular i'm not sure that i would be able to differentiate all of them maybe i have to reach out to or if anyone here in the group knows so i can share a list and we can add it pretty much anything that mentions like

east underscore something in the title is jsonrpc or if it says jstrpc in the title like if you take care of those two classes of things that get rid of like 95 percent all right i'll first prepare the list and then we'll get it reviewed with one of the editors then we'll try to create issue and work with help of community to start this particular category of eips i'll see if i have any more question on it i'll bring it up in the next meeting as well but yes anyone else has any family comment on

this all right uh moving on to the networking eids so i talk few authors and have created respective pull requests to move these proposals into the right status i think there are only a few left uh in the review status and draft uh 86 have created a good request today to move it to the last call other two dano responded by saying that it depends upon the get

team and i know micah also has said that so i have left note for felix and waiting for his response uh the eip is in draft i am not sure i left some uh comments for peter uh we'll wait for his response if not it i think it can be superseded because we are moving ahead with each 66. does it make sense to move it with uh i like the superseded with 66 um no for two reasons one um i think we dropped superseded because it's too opinionated and two i believe e66 actually depends on e65

and so technically um let me verify that i'm pretty sure yeah e66 depend it requires 865 e65 requires 864. so technically um we shouldn't even have moved 66 to last call or to review because 65 and 64 are still draft like those ones should be moved at least at the same time if not first does 66 depend on 65 yeah they mention it in the proposal yep it's a hard requirement and okay uh so what i can do is like i can

create full request to move it to review status for 64 and 65 and maybe then uh like ask the author to approve it and we i already have created requests for 66 to move to last call we have 14 days we'll try to sort this issue within this period of time before moving it into the final status and that about uh 1459 uh they know discovery by dns i think felix would be the best person to comment on it okay i'll check with him one more time all right i think this particular

category seems to be in very good shape like this is under control proposals are mostly in the right or appropriate status there are very few proposals in fact and it is manageable good to know that and about the last category years erc a few months back we decided to leave as it is and revisit after a few months to see if this needs a process change just wanted to have a quick check with the group like do we still feel that the way it is moving is fine we can just use it use the github labels to address erc's or

the process that we discussed earlier should we try implementing it i still would like to get rid of ercs out of the ev's repo causes so much i love your determination micah so uh you know earlier we discussed that we will be waiting for some more time to see how poor eips move ahead uh if we are moving into like completely the quarry it is out of the eip repository then we may not be uh moving erc's but as it looks like we will still have four eips in the

github repository uh as it is just a part of it is taken out of the github repository a github eip repository so i think uh the changes that we discussed earlier for erc's makes sense especially uh in terms of taking their numbers and the process like having a separate repo and uh process to be followed similar to eip but managed separately if we think that we will see a switch over to the f1 specs like uh the python specification

like within the next 12 months then i can probably be swayed to give up on getting erc's out because when that happens i will just stop paying attention to the ips repository um i think for me the issue is i'm not confident that within the next 12 months we'll be off of the eip's repository does anyone have inside information that i'm not privy to that would help convince me i mean we'll have a spec written within the next 12 months and it's a matter of for people wanting to switch to it and i think they will but it's not given

where would one go to follow along with the progress of that the eth 1.0 specs repository i think the link is there in the consensus specification i mentioned in this particular item oh is it just being written right in there yes okay uh in the meanwhile i'm just wondering like i know uh now that we are having this meeting of eips and editors and training so we are trying to cover more and more eips as well as

erc's i mean review at least uh i don't know if we can add triaging permission to more of the reviewers with that help we can't give triage permissions because the ethereum organization is not the latest version we don't pay for github enterprise and uh you need github enterprise for that i'm sure i'm surprised because in the ethereum cat heard us get help it works i yeah i i i tried and i asked her devops team i don't know that's you can give triage permission in

any cat herders repo that's right i mean let me try in in the ethereum organization no cat order is out of ethereum organization but i'm saying that i'm also i mean like ethereum cat is also is not a paid version of github yeah yeah so which repo this is for the eth1 specs right uh no it is for eib oh okay let me try so i think the issue here is there's a different there's multiple versions of github there's github paid github private and there's like legacy github private and then there's github enterprise and there's legacy versions of github enterprise um i'm guessing cat herders is on just like the traditional public

repo whereas the ethereum organization i think is on like one of the older oh well i think the thing is we are maybe not an enterprise but like probably like a paid plan we're probably like in this like weird middle um we're like we are like an organization but not an enterprise um because like yeah i i anyways i yeah i okay there's like a team plan so i wouldn't be surprised if like we were on the team plan so we get like the worst of both worlds yeah i think i don't think you guys are on the team plan because the team plan is like a what a new thing right i believe you guys are basically grandfather the

ethereum organization is grandfathered on a plan that no longer exists like you cannot get this plan anymore yeah and i don't want to leave because leaving would change the pricing model significantly and i just check on the eips repo i don't even have access to like see who's in admin and see the roles so um okay notice then in that case yeah i was just wondering because i found that lightline added to some full request that it is an erc and it was really easy to sort it out so i was wondering if i can also contribute or other people who are trying to understand the eap editing part maybe just because this is the primary thing

we can do it without too much of effort but no worries okay so that sums up the evolving eip process agenda item listed here uh on eip's site rendering issues um i think this was discovered in the eap 3675 michael also left some comment i left the first comment because when i was trying to read out the file that was giving me a 404 error so i suggested to move out the anchor part but it seems like there was some rendering issue not sure if it has been solved or someone needs to look into it

i just made some changes recently have you checked since then not today morning i checked last night i think i think he made some changes today to try to get the anchors working so i'm probably worth checking again all right all right then then it sounds good yeah because i was trying to understand like why is it missing and when i'm seeing why they're doing 404 ahead to me but that's all good i'll look into it again um there are the next item is eip bot alita mentioned in the comment that she may not be able

to attend the meeting today uh but she left some updates on work she has been putting in for eip bought a few issues i have highlighted earlier was a proper representation of eip that eip dash whatever the number is i think that would be a good practice to let people know that whenever we are referring to eip that is something that we need to do and my assumption is it is fixed because for another pull request i i got it in a better format so we considered it done i'm not too sure about the the next item uh if a user get a specific message about why a pull request failed checks because if i look into the

list of pull requests right now most of them are red cross that means they are failing vote check at some point but i'm not sure if i'm receiving specific message what is failed i mean why is it failed and how i can fix it to get the green check so i think all eips will have a red check right now yes actually it is yeah i think it is as soon as it can get a green check it merges like that's how the merge works basically oh so it's not possible to get a great change before that because i remember when uh yeah the current bot

you cannot green check it like it's the green green check means your merge basically uh if you hover over the check mark it will say like two of four or three or four or one of four or four or five something like that right um in theory you can get something some information out of that or if you click on one and then scroll to the bottom of the pull request you can see which checks are failing which ones are passing if the failing check is travis ci that means there's something the user probably needs to do like there's something wrong with the the actual eip like it's got a spelling error or it's malformed something like that if it's one of the other ones it's just the waiting for the

waiting for approval basically that makes sense but it it is not able to pinpoint what is wrong like when i was into such a situation i took help of you and like and you guys pointed me that i should add a dash between eip and the eap number and i got a green check but that was with the earlier bar and i don't know i mean is there a way that yeah so yes right now it is definitely not easy for end users to understand what the problem is usually as editors we look look and see what the problem is and then tell them in a comment it would be great if the bot could comment on the on the ipsl for on the pull request

itself saying hey you need to fix this thing um even better would be if it offered suggestions on how to fix it like for the spelling errors the bot could just offer like a inline suggestion but all this requires engineering effort i think we have to build something yeah right right yeah i was just wondering like if this can be considered as a feature update to the present eib bot and we it's a reasonably sized task depending on how good you want to make it um especially getting the travis stuff out because it requires some like uh integration the other direction which is complicated so it's not a small task

got it okay so we'll uh consider this uh in that task list but we'll have we'll have to alita to also give her some feedback on this ah how long or like if she would like to have more people engage working on this or whatever we'll talk to her uh also the next item is metrics i mean the sub item is metrics i'm wondering if there is a way to get collect the metrics of how many proposals are like being proposed if not new proposals let it be full requests or issues coming up every month or every week and how many gets the reviews

comments and how many gets closed or any kind of metrics is it possible to collect data with the help of github or maybe we can design a part with that definitely possible but again requires engineering effort so this is not currently possible with the help of github um they may so if you go to the insights tab in github oh yeah that's what it is yeah what was that oh it's like github insider pulse yeah github so if you go to the repository and then go to the insights tab at the top they have some kind of basic high-level stuff um i'm not sure if that's quite what

you're looking for like the things you list that i don't think are included in the in there they're very high level um yeah i i see that too but these are just yes as you mentioned it's very very high level like multiple requests or people request something like that okay then maybe first we need to determine what kind of metrics could be helpful to understand like how we when we are getting the request from community and then to see if this is helpful and if not then maybe look into the part well because yeah please go ahead as you can say somehow i fell into

fourth place on the eips repo that is surprising very sad day yeah that is surprising because i know like uh you and lifeline keep on commenting on most of all of the pull requests not sure of the issues but but yes well this this is for commits not for comments okay so i keep this open as well like i'll check with anita on this and we'll try to see if if we can get a list of metrics

that can be helpful and then probably try to put in some work in this moving on the next item is eip erc editors in training progress meeting so we had this meeting yesterday and we covered i think the five five over five proposals so reviewed and uh they left comment there um thank you likeline for conducting these sessions uh james hancock also joined us yesterday so we now are getting more and more people involved learning the process and i hope that uh with with this rate if we keep on working we would be in a position to decrease the number of

at least pulled requests first under 10 and then we'll start considering the issues section okay um the next item is json rpc api spec um progress i think alita left her update on the comment that we are nearly done collecting the necessary data to write edge cases and are well into finalized track to begin the client review process the open rpc spec needs another review from my client so um lifeline if you might want to look into the open rpc specs and she mentioned about a blocker i don't

know um if if someone from here from the group can help it's about finalizing the format for the edge cases in the open rpc spec this requires that we first merge in previously discussed open rpc second and then i will open another discussion on this point um unfortunately i do not see too much on the call but yeah anyone likely and micah if you guys have any thoughts or suggestions on it i think we agreed previously to just move forward with everything except for that and then internally they can use whatever format they want and then before we like publish it we will have a discussion and try to figure out what the best format for that

is um the impression i got was that no one's really in a rush though to solve that problem all right i i'll ask elita to follow the recording and then maybe she can look into it um maybe in the channel that the discord channel that is created to discuss this open rpc moving on the next item is the progress on canonical source for eips of wap dark i see print on yeah i'm here i i was able to i'm trying to get my head around gatsby that

it uses i've got gatsby installed on my personal machine i got it up and running but evidently one of the servers is configured with not enough memory i'm working through some problems on how to get that so i haven't got anything to show yet but so i'm hoping to be able to understand that system and be able to make changes and then be able to propose changes and show people prototypes and stuff like that but i'm still still working on it and so hopefully in the future i'll i'll be um able to easily contribute and help a lot of the some of the stuff that we'd like to help make on that system so still just learning the system all right thank you for the update print the last item on the agenda is review

action items from the previous meeting unfortunately the previous meeting uh we did not have the recording it was a very small meeting and we have covered most of the item that we discussed there um yeah i think we covered almost all of them the sub item is eap draft banner a shout out to felt a discord user who took up this issue and have submitted the pull request which is actually merged right now and we have this banner available on eips.ethereum.org about every proposal like what is the current status of the proposal and

what is the expectation with it like if there is any change expected or people or it is ready for people to use it so thank you so much for submitting the request for that the uh another sub item is bought tracking inactivity period and changing the state of the proposal uh that is still open um alita mentioned in the ethereum meeting that she would be looking into this issue and uh we'll try to get it done this month so i'll wait for her response uh to finish it up but there is this one thing that i found on a bot's comment um if i remember correctly the agreement

was for over 90 days period right like if uh any proposal or any pull requested inactive for three months or more then the bot should be sending a message that this will be closed soon um i don't know i saw somewhere it is two months or something like that so does anyone remember what was the decided period there or maybe i will go back and check in eip1 because two months seems like very small duration generally any proposal or pull request

it takes some time for review for people to comment if that is not very hard proposal so you might want to keep it open for a little longer if that has i'm ambivalent to the specific time frames like i don't care i mean obviously we would like that if a proposal is here the champion or the author should be around to push it we do not want it to be hanging in the pull request repository for very very long time but having said that we should have a like a decent amount of time provided to notter

or the champion to talk about that proposal or any any pull requests that they have created and after that part should automatically close that i'll look into the specifics one more time and then maybe bring it in the next meeting that concludes the item listed here on the agenda anyone has anything else that they would like to bring up today all right we are closing early thank you all for joining us and see you all in two weeks thank you thank you thank you michael have a good thanks