EIPIP Meeting 62

Transcript

welcome to eipip meeting 62. i have shared agenda in chat the first item i have added it from the issue that was submitted yesterday which is make eip authorship depends on ens i find it very interesting not that it is very important that's why it's in number one position but kind of interesting would be curious to hear thoughts from people um just a second grit i think i'm hearing echo from your end if you can maybe mute and yeah if people have any thought comments i mean personally if it can be

done i would prefer that um but it's all about whether or not it can be done obviously how do you prove ownership of the e s name whenever you're creating an eap because i could just say oh like lines on ether to cap just so i don't have to register one well you could do the same thing with emails right now yeah but you have to have a github account right now and we don't have any requires basically the ens is going to be used as some sort of civil resistance mechanism and so

if there's no mechanism to enforce that that person has ownership of it then it's not really doing its job and so it's just adding an additional step i i wouldn't say that a s should necessarily be required but perhaps recommended if you have one example notably i don't have an ems name yeah if it's not required i don't know if there is a big reason to do it i think this is more about

decentralizing the actual repository location itself in case github decides to uh have the erp's repository go the way of a tornado i see i'm much more worried about a nuclear explosion in ukraine or a major thermonuclear conflict or other things that are far more important than the eip repository there's there's clones of it all over the place it can be reconstructed yeah i think it i think

it will add a lot more um work to to process tooling we can write as much tooling as we want to make this work and to be less reliant on github but i don't think that the benefit outweighs the the required work perhaps we could have like a mirror on gitlab just in case so everybody's local clone is already a mirror technically so i don't think we really need like any of us can put it back up anywhere whenever we want so like it's not like we need the mirror

now we can put it up after something goes wrong with github i think the hardest thing to back up and i'm not sure what tools we have but keeping track of all of the issues and the comments on the pr's is difficult and that's not something in your kit your local get repo normally true but it's also less important uh i don't know i mean maybe for the e problem yeah have user names too are kind of essential not sure what would happen if like the the majority of the uh yeah uh eip

editors perhaps got banned like if there's no one to review for example corey ips then that would probably be a problem i think we can move on now yes of course i mean like yeah we can probably continue collecting thoughts on the issue the issue is added on the um eip ib github repository moving on um we have collected some issues and pull requests from the github issue of eip and what i guess also okay part is at number three

um in the last meeting we were discussing about eips and erc's uh like how do we write it how do we read it and there was one important discussion uh that was how we should pick eip numbers i'm not sure if there was any final decision on the way we should use eip number or erc number so yeah people can share thought on that and then we can probably pick up uh how we should pick up eip number i guess this was suggested by sam uh i think the discussion was basically like since we had difficulties about eip numbers we should make a bot to do it and

i'm totally for doing that if you guys want well i kind of it kind of depends on whether or not we want to do the eip number nfds or not they're kind of computing proposals i think the the nfts were historical right so we'd set the eip bot to start at like whatever the current eip number and then we'd auction off the holes i think that was mica's proposal uh my proposal was actually that we had assigned the eip bod itself some of the nfts can use the nfts so i think i'm in this case i'm for the

simplest solution which is just have a counter and a sign uh based on a counter um but you know if we want to go the nft road i guess i'm not super opposed to it when i i talked about the nft routes with like some of the client devs and there was definitely some amount of pushback um and i guess the like highest level one is people feel like this is not a decision that like just vip editors should make like i think when you like basically auctioning off a common good or a public good and i think if people do want to go to nft route like

i it would be good to get like a much broader set of like input into it um because i suspect if if like we just go ahead and do this and like don't tell more people um some people will be like mad or like yeah uh disappointed that this thing that kind of affects how the governance is handled is like being done without them being consulted um so not that like it's it's impossible to do it but i think that it's definitely something which would require like a broader buy-in um because otherwise it looks really bad if

like you auction these nfts and like cordell say this is a terrible idea you basically lose all the like legitimacy to your mft um yeah well technically right now the editors have full power to assign an uh to assign eip numbers right so so it's something yeah it's not the assigning the numbers i don't think any client death cares about how the numbers are assigned it's the um like auctioning off the public good bit i think there's a general consensus among the editors though uh correct me if i'm wrong that the numbers themselves do not matter to us at all

right i think what tim is probably saying is that we um if we were to auction off nfts it would make us look like we're taking more of an active role in assigning uh like using our using our power in a particular way to assign numbers and the core devs might disagree with that it's not even the assignment i think i think cordevs are pretty ambivalent about how the numbers are assigned i think it's more to like generating a sale like selling the public good in a way right it's like if the nfts were free i think it's still kind of a well i mean the plan here is that some of the nfts are free

oh sorry i thought that no only only notable ones would be auctioned okay anyways but i do think anyways just because it's like a a largest change in their process like i would get their input and i'm not saying that like they will be against it but i'm saying that like doing this without getting input will probably lead to pushback um and like some people might be against it but it's like you know you get like rough consensus but i think there's a world where like this happens but i think it's much better if like yeah client devs are on board with this before it happens rather than like opposed to it after it happened i'm going i'm going to block consensus

on it regardless well i guess we are trying to like uh address two things here one is about nft sale of eip number and uh help me understand the proposal of how we should be eip numbered is it dependent on the sale in any way like if the sale is not happening okay i thought we agreed the bot would simply pick up the series and start assigning the numbers so that we could stop arguing about or caring about the assignment of numbers i thought we'd agreed to that

and i can't see complicating the bach to try to go picking through old numbers and i'm going to object to any going back into the old sequence to assign numbers i i will strongly object to that that seems fair to me okay so i guess the decision for now is make a bot that just counts up and assigns numbers perfect specifically the one that bases on the uh the pr number okay now forget the pr number that that's just been a hassle okay so we'll just count up and it's at

at merge time i think is what we agreed on probably yeah okay whatever the lucky person to get pr number uh to uh get eip9 yeah i mean exactly when it happens i'll leave to the bot authors because i know that's a dicey process but um they're just a number let's just assign them sequentially then there won't be so many holes in the sequence they won't stack yet they won't get so big so fast um and we won't lose editors over incredibly stupid arguments all right

um so yeah i'm just trying to repeat here so we are good with the bot proposal uh that is there with five to nine four and we are moving ahead with that yeah i guess just on point of the bots it seems like there's two different understanding okay okay so sam okay so you find the biggest number so we don't start at eip9 we started like vip 5000 something is that correct yeah exactly yes nice yes i i yeah i prefer that personally so wherever we are today the bot will start counting from there not going back okay that makes sense

okay cool and uh i had listed this nft sale uh one-time sale of unused eip number that was on the later part of this discussion but because we are already discussing this probably we can address to that so if i understand correctly that was the proposal for unused numbers so far it was not for future numbers like not auction for future numbers so that is not going to affect the way bot will be assigning number in future that is one point and the second thing is like where are we on that if i understand tim's correctly it is like we do not want to fundraising and have it used somewhere else of public good but

if that is for free well the plan was that some of the numbers would be free and assigned to the bot that assigns the ib number but if it's a one-time sale the previous number is um well we should run it by the core devs first i guess is probably what's going to come out of this right all right um what part wait a minute what part of blocking consensus aren't you getting here i will block consensus on this it's an absolutely stupid idea they're more important issues anyways

all right okay uh then i'm gonna drop it from the agenda and uh we can probably take it from the issue that is added here if people are strongly in favor of pursuing it we can have it done if not then the issue can be closed eventually anyway we have bots which closes issues if they are not under discussion for like over three months or so so that would be taken care of um moving on uh the next one is fixed eip bot i guess this was suggested by panda peep would you like to take it yeah so basically uh for a while now the eop bot has been broken spr just fixes it

micah refused to mikey just now refused to merge it without another editor approving so if uh someone here would like to approve that i can then ping micah matt would you like to look into the pull request because i understand you may be able to merge it if that's i mean if the pull request is all good to go yeah i'm looking at it oh thank you anything else you want to mention on this one otherwise matt can respond to the issue or the request well there's also going to need to uh be some changes

after it has merged to the uh branch protection settings so require review from code owners is going to need to be enabled uh enable dismiss sale uh pr reviews is also gonna need uh need to be enabled and uh the eip merge bot is actually going to need to be removed from the required checks but that should only be done after the pr has merged not before um are we anyway discussing about the point number three using setting.yml for this um [Music] that is a completely separate thing

i think we're currently putting it on hold for now just because again there are more important things got it so there is an ongoing discussion thread added uh here the link is added here on the agenda it is about some setting changes requested uh on organization level uh people interested may look into it and they can also participate in the discussion discussion is happening on issue eip github issue as well as on qatar does discount any specific point if i'm missing given on this one

okay cool thank you item number four is a sub item number four is add license checker do we need any kind of consensus on it well i mean micah i think was the uh biggest objector here um it's now been a change to only check for solidity files and then required that the license be explicitly cc01.0 and reasoning for this is that a lot of people try to do things like mit because that's what open zeppelin uses apache 2

for some reason is another one i see a lot of uh in in general well they should all be cc0 and since the solidity style guide actually requires you to have an identifier um this just forces you to have the right identifier we found this issue in the eip editor's apprenticeship meeting yesterday but it felt like it might need bigger audiences and that's why we have added it here to the eipab meeting any thoughts from any of the present participants

well my guy is not on the call today so maybe oh my anymore yeah he's retired yeah that's true so yeah the rest of the editors actually specifically did not want to actually specifically told me that he was not planning on coming yeah yeah he's probably not going to be doing anything more and yeah anyways so i don't think we should limit assets to cc0 i think we should allow you know any open source license that isn't uh copyleft yeah i think that's a separate discussion though since right now it is oh cc0

and currently so eap1 doesn't actually say that eip1 only says that um the eip itself needs to be cc0 but it doesn't saying that the assets are not part of the eip yes so if you put your reference implement if you put your reference implementation and the specification in the assets folder then you can't then link to it well a link is not directly including right that i mean that's the whole point of lgbl so like if you link to your asset it then isn't part of the eip itself well

then we i i would argue that anything that the eip links to for example files and assets folder are part of the eip all right well we can discuss this offline and figure out what license we want to use we don't need to do it like on the call but we can agree that it should be limited right yeah i think so cool uh we can take it on github moving on the next one is add ech discord channel to eip page index um this is again something that

was there for ap apprenticeship meeting but we felt like a broader audience may be good to have a consensus on this particular topic do we want to have ecs discord channel be added to eid page index uh i don't remember any uh precedence of this other than ech github repository but this is something out of that well i mean there's a link to the erp's getter which i think is possibly even less official than the ech discord i'd be okay with having it there yeah if the gear is there then yeah we can definitely put the kid or the discord

there but the only problem is that currently they have typos in that thing so they need to fix that before it can be merged sounds good guitar is something that we are definitely not using and um i am just concerned because i understand any discussion on eip level part of it in fact big part of it also goes on with our data score we are definitely encouraging people to make use of cathedrals discard and make a discussion here so we do not just like uh overwhelm the ether and a discord server but i am not sure how good or bad it will be because

eip getter it was the only place for discussion and that was independent of uh discounts well i mean there was also magicians too but right somehow their magicians wasn't actually listed isn't actually listed on a front page as a place for discussion so that's interesting right yeah matt mentioned there is some good content in the guitar of course yeah totally up to ap editors if there is any concern about adding a ecs

discard to the page github page i'm fine we can let the user know about it you can definitely add your feedback on the pull request the number is added here it is 5415 and if if there is no objection probably with the minor edit that gavin suggested this pull request can be pushed moving on uh the next sub item is bug explain in text that erc was renamed to eip well this is um this is all together a good discussion and i i find a comment from greg like

was it made final was there a decision i am not sure of that so let me open the floor for people if they would like to share their thought i remember we discussed about it but at the end it was like me and lifeline should be heading this discussion somewhere out of the room yeah any thoughts i don't care what people refer to it outside of the actual markdown files they can call it erc20 they can call it banana 20. it doesn't matter to me but i think in the documents we should call everything eip this

on the side note people often refer to non-existent eips such as like eip223 eip23223 is an issue it is not an eip yeah yeah there was the the that same issue was 67 too 67 is in the ip no doubt now though so that's i guess yeah that's a very good point instead of arguing about what we should call an eip like whether an eip or an erc let's uh take smaller steps and uh first thing first would be like call eip when it is only existing in an eap repository not in like issue form or

repository of somewhere else because there are many other chain that call their proposals also as eip i don't know why but yeah so that is there and i am a strong proponent of like they are free to call whatever they want to call they can refer it to whatever they want to refer it but if they are using uh eip dash 123.md then it should be there at least for documentation purpose um greg do you have any concern oh sorry matt you were trying to say something i saw on muting please i was just saying to say i think we all agree that

we shouldn't refer to issues as eaps there's some legacy issues that sort of were from before this time where we were as hard about making sure that things were marked down files but you know we're anytime those things are referred to and new ap eips i think we're requiring them that they merge them as markdown files so i think we're all already on the same page with with respect to anytime i see anyone refer to eip223 i immediately point out that that thing does not exist but i still think that we should allow people to continue using erc if they're referring to an eip in the erc

category yeah and i think also that it should also i i also on the side note if people want to merge their like legacy issues as markdown files in the withdrawn state i think we should probably allow that yeah i think we do yeah 67 is a very good example of that that has been done recently so yeah um greg if you would like to uh like uh share your concern or comment related to this issue yeah i sort of came in and out of this discussion and it's gotten scattered

across a lot of channels as usually happens so i had thought the motion was more towards actually calling erc's erc's getting clear on which is which as a way of dealing with the should there be two repos issue because we keep wanting to do that and deciding it's just would be way too much work to try to take them apart but that's simply consistently using the names could distinguish the core and near core erps from the much larger number

of what are usually called ercs that have no effect on the protocol at all and there can be lots of lots of them and it's you know it's not the same sort of problem except that they're just sort of cluttering up the system because they're all called eips it's it's just a confusion that's worth resolving one way or the other but i don't think we can get rid of calling things erc so i'm more in tune with just try to always call them ercs and if people wonder it's like well yeah historically you can also call them eips and you'll confuse people a little but erc20 and eip20 are actually the very

same thing don't worry about it well right yeah i agree to that part like education is very important here yeah there's just there's so much history and confusion here um that i don't know that we can ever really straighten it out okay uh talking about the documentation purposes i understand um the new bot eipw that has some chats which is uh like uh whether it which is for the way it should be documented um would you like to share something on that sam like how is it performing now what what it is

considering now or do we need any change in that like for the erc versus eip um yeah we just have to write a test we'd have to change the test so that it checks the type of the linked document to see what it is right so when someone is documenting a proposal and if they are trying to refer to an eip sorry an eip of a standard track erc category how they should write it is it okay to write erc20 or they have to go by eip20 for that so right now it's right now it's eip only but like we'd have to change the test if we wanted to change the rule we'd also have to change eip1 because here eip1 specifically says

that in eips it has to be referred to as eip hyphen number okay okay all right so i believe uh if people are willing to make these changes uh they can definitely create pull requests respectively and i suppose sun can take care of the bot so is the consensus now to go with erc for ercs i don't see anyone objecting

i'm objecting but me i don't i don't care that much i i understand the objection that there's no way to do this that won't cause confusion i don't care that much either yeah at this point i'm also fine like moving ahead with whatever people want because i'm sure that there are more important issues that we can probably bring up however i was thinking that it would be better time when we are definitely separating erc's and eib then we should bring this up and do it but fine let's go ahead with that that is interesting matt

yeah cool yeah i i want him separated i'm probably not alone because there's so many ercs and they clutter my mailbox and i'm having a hard time setting up the filter to send the ercs down to the folder that says skim these and send the er eips into the folder that says study these so simply getting the simply getting the names consistent will make it easy to write the filter okay yeah that's a good question

i have no objection i just wanna [Music] uh documents to make it consistent in this way or is there a decision there i'm fine either i couldn't hear anything you said me neither oh i ask if there is a decision to also change all previous texts uh to con to

make it consistent with this new policy yeah um if i understand correct like uh this is a flexibility that is being provided in in the past people have been using eips and ercs whatever they wanted to however in eip1 we made this change to reflect that while you are documenting you should probably use it as eip now i it looks like the group here decides that we don't need to be very strict on that and we can go ahead with whatever way they

would like to use it while documentation and they would be referring to file where it will be eib-123.md but yes on documentation they could be using anything they would like to so probably yes eipw part might need to be giving that flexibility otherwise it was a blocker there sounds good one all right maybe we can move on and the next one is a create an eip external link archive part so i'm going to say that's completely

out of scope for the eip editors to discuss if somebody else wants to do what they can but i'm not gonna spend any time on that perfect we're not gonna stop anyone from doing that yeah i started one uh and i put it in my own the repository to begin with it doesn't have to tight be tied to ethereum but if you find we find it helpful then we can integrate with the action like github action or anything like i will i'll get more concrete prototype and share with the editorial group and see what people think well the good thing is like we have a number here it's five four zero eight

people can definitely add their thoughts um on this issue and if they are interested to uh like pursuing it they can do that so i probably will drop it from the agenda for the next meeting i would not bring it up because this is not something that is concerning eip editors the next item listed here is panda peep added as a maintainer for the eip bot repository there is already ongoing discussion but it would be interesting to hear thoughts from present eip editors um there was one one other thing that a proposal from my end the present eip repository mentioned names of contributors

my recommendation was to remove that section because the repository in itself displays the name of contributors and we don't want to have contributor name at one place because this is an open source repository and we would like to invite participation from community without giving any special treatment to anyone the two questions here we would like to address do we need to have that contributor section in readme and number one which is a panda peep to be added as maintainer of the eap bar repository for number two github just as a sidebar that lists all the contributors and if you want the full list you can go to

insights and then contributors and you get a list i am in favor of um i'm sorry victor you are breaking um can you maybe a little louder than probably will be able to catch it i i yeah thank you i am in favor of maintaining a contributor list i think it will promote the contribution sounds good

can i ask why because if any in my opinion that there's if someone wants to see the contributors list there are there are git commands you can use there's the github sidebar there's like actual full contributors list that gives all the commits they've done the number of files changed the added lines the removed lines you can also see commit history like there's a number of places where you can see where people have contributed um i would be okay if we started using version numbers and uh and uh

and like congratulating new contributors uh when the new version releases um but i don't see a need to have it in the readme maybe a contributors thought a contributors rc uh document might be useful i oh so just to thank you for asking the question by uh panda and um i think my proposal is to maintain it somewhere and if it's sufficient to have it on github we can like have it synchronize with somewhere but it doesn't have to be in um in with me so i can i can further discuss with you to get some consensus

on where to put it or other way to recognize it i'm in favor of the general direction i'm not like a strong strongly preferring one way or another where they put or uh how we are doing it so if uh if you wanna we can further discussion on this on like the exact cool awesome um another question for you maybe panda paper for you if uh what do you mean by added as a maintainer do we need to get you some special permission for that or was that maintainer say this basically meaning that i can

basically meaning that i can merge pull requests because mica i'm pretty sure is the only one that can do that right now um currently that is with matt as well we had two maintainers in the past and i have already requested the devops team to provide access to samuelson as well um yeah i'm fine with that for having one more editor on just wanted to chat with the present set of editors group so i'm not requesting i'm not requesting a mention the mentor status but i think

it's fair to say that i'm in favor of panda and getting this as well um so long like everyone is like if that agrees that there's a consensus between these men and women that they can be more true right so basically i'm requesting right permissions i am not requesting admin permissions i don't think i should have admin permissions because just because that would allow me to do things like set that yet uh the eip bot uh thing to private which would just completely mess with the workflow um but i think we need at least some someone that can merge the pull requests

complete and that is on behalf of the school so yeah i'm in favor of for you to get that count um i i suppose it is okay we can take it uh on the diff card eip bar repo if i understand correct yes the eip hyphen bot repository uh yeah i think i did get i'm not sure if uh i have right access or not oh never mind apparently i do

apparently it oh yeah well i don't need admin well let's take the issue is resolved we can probably move on in the interest of time okay um item number three here is uh eap bots related discussion updates agreement on merging pr's and closing issues i believe we were looking for some consensus for these pull requests to be closed yeah again that is by panda beat so i believe one of them has already

been merged pulled request number 109 but there are two open if editors may take a look at it number is one one one and one or five so micah didn't want 105 merged because he wants a full end-to-end testing basically me like using a clone of the eip's repository using the clone doing the whole work flow of submitting a pr having someone else to prove it and it being merged um i added test cases that test if there is zero editors approving one editor

approving and two editors approving just to verify that it will only merge when there are two or more editors um but i didn't do it manually this was an automated test and i think mike uh for some reason has some guams with that since it was fading before i ended the tests and was passing afterwards i'm pretty confident that it works also because the entire change is changing a one from a uh not equal to zero to a greater than or equal to two but i understand when the bar tripper was

created that was being tested by one of uh cat herders i i'm not sure jose um if we made any progress on testing environment creating testing environment how far along we are there in making that environment hello yes we exactly with mica we create the environment and well you use me to you can use it but i i told panda that you have you didn't have an environment either i didn't understand why you were not able to

to go to the i to the test what i assume is that what you're trying to test is the new architecture that you are proposing correct me if i'm wrong the reason why it's because 109 was merged uh less than an hour ago so i wasn't and i had my eip hyphen clone repository set to test that because if you have your test done in your own environment you just need to document the pr with the test that was the last in the the instructions that i remember from micah you just need to comment your test result in the pr and the

[Music] and when and i guess that the merge will will go i mean that's that should be the standard procedure you want to test a new code or new architecture for the bot you clear your you create your testing environment with the with the clone with the fork of the eip report and the you get the test successfully and you recommend the pr with that comment and the merge will go i don't know is the process of hitting but that's that was the process that i have been dealing with for months i don't know just let me know if this is like that or is something new that i just missed

um so i guess that is fine but then why have the test cases if they have to be manually tested anyways like the test cases don't lie like the test cases fail then it means that something's wrong if the test cases pass and you've added tests that successfully fail if what you're doing is wrong and past if what you're doing is right then i don't see the need to have a dedicated testing environment well i don't i don't want to go too far

on it but i just what i you understood and i don't agree but always when i'm willing to accept whatever i decide for you the editor is that if you want to test code you need to ensure that the call is doing what it's supposed to do as the clone if the the clown test the code that fails so the the call is gonna the code is gonna fail when when you go to the original repo is the call was it's gonna work so if this want to be changed by doing it manually which i don't basically

you understood how coke could be test manually i mean and that's fine they're supposed they're measuring their there should be something that i don't know okay i will go with it i will test my new proposal manually and that's it but so far from my point of view the code should be tested in the in the in the environment uh running your test case documented and ensuring that it's working even even if it is the test it's gonna imply changing the the architecture of the god or or

whatever is the wrapper in this case is the body um but if you guys as i said if you guys the editors this the size something different that's fine and i'm just a contributor and i'm just trying to you know to to get my grain of sand on it and i will work on it i will contributors we don't want to be a dictatorship um gabe and i i can weigh in in some of the uh rationale for uh suggesting of a unit test and then end-to-end test uh even though sometimes i stick it skip test so i can totally

understand the burden and overhead it brings well there are tests there are test cases that mock responses from github there's just not a test case that actually runs on a production environment right um i would say yeah maybe i would i would say the rationale uh to suggest that is that it makes it easier for future contributors to contribute and so that the original authors will be notified if something goes wrong and no one are obligated to understand all their corner cases the change can bring into so that's the benefit but like whether it can overweigh the overheads it brings

to is up to your prior top priority discussion just providing a rational for how that can be helpful and maybe you can take that into the consideration when you ponder it on so one question here given um for testing as you mentioned in the chat like there would be three testers needed for it right so um sam has a question here like is there any specific level that is needed or it can be any three person contributor or eep editor can do that so

currently there are automated test cases and then there's end to end test cases that mica has been requiring all the prs to go through so the automated test cases mock responses from github they run extremely fast four minutes no interaction necessary or even less some of them running actually i think most of them run in less than an hour a minute and a half um [Music] then but then there's also micah who wants an entire basically what i did was i set up an entire clone of the eip's repository with all the edit with all the editors sam and got sam to uh basically

i set up a pr uh submitting a eip with a number one two three four five had sam approve it and made sure that the bot actually went through the entire process of doing everything but i don't think that that's necessary for all changes basically what i'm saying is that i am really really really certain that the automated test cases are going to

catch everything victor your hand is raised uh is it from the last time or you want to learn something more it was from the last time of apology not a problem yeah i mean like if the confidence level here is about 99 or so for that that it will be debugs will be got with the automated testing sounds good to me but yeah to me like basically you've been given right permission to the repository you can decide what level of testing you'd like to see on it um and if there's a problem down the road

like if bugs get in then we'll bring this discussion back up but for now decide what you want to do and go with it i don't think it's really an eipip decision and anyway we can revert back if something goes wrong right we can go back to the older version there yeah it's yep well i'm also not planning on submitting a new pr every time something changes to the ipod it'll be like a whole batch of changes that then i'm okay and to end testing i'm okay i'm okay with end-to-end testing every time i need to submit a pr i'd rather not have to do that every time a pr comments into the eip uh yeah repository sounds good i think with the right

permissions now you may be able to decide on which all testing you want to go for end to end and yeah you take your important decision here and if something goes wrong we'll take care of them we have just five minutes left uh so um there is one last important item i can see but i'm not sure if that is important for this meeting today or not that is about the meta e for executable spec process for core eips i know it was discussed in the all coordinate meeting uh last thursday i believe do we want to continue discussing this item here in eipip meeting or is it to

be taken there on easy i guess from the coded meeting it seems uh obvious that people are generally in favor there were some changes that were recommended uh by core devs so probably uh we can look for new proposal one thing that we wanted to uh discuss here earlier it was a creation of meta e i'm not sure we are there in the draft status yet right i don't know if tim or sam any of you

are talking i can't hear you must be muted sorry what was that i i missed okay no i was just wondering like we discussed about creating a meta-eber so do we have any draft of it i know there is an accounting file which was shared with an all-quarter meeting uh but we are still in the process of documenting it right yeah i don't think we have a formal proposal yet fine would it be okay to drop it for um future meetings for some time and when we have that draft right then i will bring it back to the agenda oh yeah we we don't need to talk about it on here for now yep sounds good

and the next one is the eip the inside for the month of august so far we have four new proposals added to the repository as draft one eip has been moved from stagnant to review and that is a eip number 831 uri format for ethereum there is one proposal eip 5313 which is in the last call and the deadline is ending on 15th of august that is light contract ownership so people if you are interested in that eip this is of erc category please uh check out the

discussion link added to the eap and other than that there were some minor changes done all these changes have been added in the eaps inside for the month of august link added to the agenda oh quick thing can i quickly merge that pr that adds the uh waiting for erp number label matt i know sam has dropped looks like it needs to be rebased

all right uh yeah i think we are on time and i'm just trying to quickly look into if there was any action item from the past meeting it doesn't look like one says that if we find any issue with eap w bot we will be taking care of that and yeah that's it so was there any discussion about how to address the relates or requires cip discussion or is there already a consensus i'm sorry i could not quite catch it

[Music] so i previously uh put uh bring up that there is a requires a part in the preamble of eip templates and sometimes that rem requires are understood as uh that that require the the eip requires pre the other eips to be ready or to be implemented sometimes i think from at least what i learned a conversation with mikko that it it was used in some way that means to understand this this eip you require reading the other one where maybe you you need to get set

more of a related eip kind of thing so which one do we go to or do we have already have consensus um if i remember correctly it was added in the last meeting agenda but unfortunately i missed to add it here in this meeting and yeah i could probably bring it up in the next meeting i'm not sure if there was any consensus on that sounds good we can put it on the backlog for next one of course i'll do that thank you um we are at time i'm gonna create the agenda for the next meeting right after this one if you can

probably add the link i will try to pull it from the earlier meeting and do that if in case i miss it please help me out over there and add the link in the comment section i will do that thank you everyone for joining us today i hope to see you in two weeks have a good one everyone see ya thank you all right see y'all