EIPIP Meeting 78

Transcript

welcome to EIT IP meeting 78 I have shared agenda and chat it's issue number two to four on eipip GitHub repository we have few open issues and PRS to be discussed today and there are a couple of items from the earlier meetings discussion continued we'll get some update on eipwbot issues one of the characters are working on it and we'll go ahead with eaps inside for the month of March and April followed by EAP editing office are so I'm going ahead with the agenda um the first item listed here is a an update that is for eip1 pull request

number is 6824 it is to update EIP want to include voting about the finalizing pull request I suppose this is created by Victor Victor if you have something to share about it and then probably we'll see what other editors think about merging of this proposal sorry can you put in the link sure just give me a skin it's a pull request number six eight two

four so this is the first item on the agenda pull request number six eight two four to include uh some wording about finalizing yeah yeah the uh the background is that um in our previous discussion uh on eipip meetings that people agree uh generally uh you should not move a move a EIP into final status with other changes basically the last PR pull request to move a stat um to to change

an EIP status should only touch the status without other changes and this is a reflection of our um of the the meetings decision um just oh it's already merged okay so um yeah yeah looks like it has been mushed uh it received um approvals from other authors so thank you for providing the background here cool thank you all right uh the next one is pull request number six eight one three uh that is to that is a CI change for bump rake file depths um I see a lot of comments here uh and

uh there are some changes made by the proposal for recent wonder what other editors think about merging for this proposal I think it just needs to be um tested um it looks like one of the builds is failing so the the CI checks so okay and I think Panda left a comment over there right so yeah all right uh let's move ahead with the

next one this is created by Panna people and it is uh to remove EAP Preamble entry um I think uh I can see a lot of comments uh there are some people in favor of it and some are not I don't see Pana on call today um if anyone would like to maybe uh say why they are in favor or not about this particular peer 6790 I mean I'm just going to reiterate what I said on the pr I don't really see much

point in removing it like it's it really isn't affecting anything it might make the CI bot slightly more complicated but it's still on standing part of the EIP process and I think we should just retain it I support that we don't uh remove it I I assure it was even stronger that I think in the content of the EIP we should have a uh have a number just like um even if you might have title somewhere you should also have the title in inside of the the inside of the content and the EIP number is an important piece of that information and

should be duplicated and double check so I'm missing the the argument on removing it so is it just um because the Erp number is in the title or in the file name that he wants to remove it it's in the file name so it's kind of duplicated in those two places well it's a little bit more than just that right like we're working on making the EIP number a signing bot and it's you know one percent easier if you only have to change it in one place instead of two places so I think that's where this is coming from but um it really doesn't matter too much

technically which way we go I create some overhead though right because it's not exactly progress compatible yeah yeah we'd have to go through and and change old eops and stuff so it's a little Annoying there yeah I mean let's just close it there's not really a strong argument for it very well um so I think one of the editors may be able to close it um it looks like most of them are not in favor so we don't have a clear consensus on that moving ahead the next one is a website remove dependency on eips Preamble it is

number 6799 and it's by Panda again uh looks like it's waiting for some review yeah this is only necessary if we remove the EIP Preamble entry and if we're not removing it we don't need this change either right yeah that's why I had it like followed by the yeah so we don't need this either right as far as I don't know okay [Music] okay if any of the editors May close

these two number six seven nine zero and six seven nine nine next one is a update code spell project action code spell digest I'm not sure if it is created by a human or a bot so I just thought of uh bringing it uh to this meeting wonder what people think about it the number is 6805 um yeah these are made by a bot this is the the the demand renovate thing that Panda pep wanted to do and um it makes useful pull requests I just haven't gotten around to reviewing um any of them yet okay then I'll I'll like let it let uh

maybe even other editors also get chance to take a look and Sam if you can because you are closely looking into Bots so yeah that would be good to have and that concludes our first uh like new discussion items our pull request the next one is a discussion continued from the past meeting um someone requested to have the first two sub items for this particular section the pull request number is six two c six nine and it is about um a full EDM equivalence in ethereum so it looks like it was discussed

earlier um I think when we had Greg on the call as well and we didn't have any clear consensus on it so after three four meetings the proposer has requested to be discussed again to see if there is any news stand um by the AP editors and if we can probably move this forward do we have consensus that execution spec should be linkable yep I think oh yeah I think we can let the proposer just split it out and then put this uh the execution first and then yellow paper I think um

Sam and Matt is against and then Greg and I were uh were uh support so we can discuss that further we want to just minimize the block on whoever proposed the link and oh is that the links that are blocking this okay well I mean they are but if they remove the links they still wouldn't let them merge this um because you can't make an EIP Force things on other eips so I don't see the point in having an EIP that just makes a definition without some sort of technical like substance or proposal right so I I don't think the content of this

EIP is suitable for this Repository oh are you talking about this content is Oh you mean yeah the content of of this VIP is not relevant to actually being on the IP right exactly yeah it's like yeah if you want it if you want to Define what EVN equivalence is for your proposal go for it but making one proposal to Define it for everybody is is not something I think we should do until I mean uh until uh when there was not there's use cases where multiple independent EIP needs a definition and that definition is non-trivial

so maybe just too early or um it doesn't make sense at all I'm looking through it it says full AVM equivalence and it's just definition of it it seems like to me like a marketing term could be done in a Blog in that case we should close it okay uh so yeah the last comment was from the editor saying that let's discuss this in eipap meeting and uh from today's meeting probably we can add a comment that uh

um editors are in favor of closing this maybe not the best place to add it in EIP Repository the next one here is pull request number 6306 it is by the same author a same proposal and it looks like um we have two comments one in strong favor and one strongly things that it should not be added to eip1 Victor and Matt if you would like to share your thoughts and Arguments for for and against oh this is actually the one that I I was confused with uh so uh I think the

proposal was to add to allow link um a permitted links and then one is to exection execution uh back which we all agree and then the yellow paper which we disagree and uh so I think we can let the proposer let uh submit a merge for the spec first and then we can wait for consensus from for your paper what do you mean wait for consensus because I feel like we rent this problem a lot where there are opinions and then we just leave it open for six months and I'm I gotta not going to change my

opinion on this because I I really don't think the deal of paper makes sense to link to it's a deprecated resource and people should start linking to the execution specs um can you make a argument that I know that is lack of updates just like execution is currently being the canonical one to update and then we kind of socially agree that execution is up to date but how can you prevent six months or a year from now the execution spec is also continue to be to be maintained and I I believe that people or the community maintain yellow paper back then when they write it when they update it with with Berlin updates they

didn't think that it will be not as it will cease to to be maintained right so the fact that you think that is currently the lack of Maintenance um I don't know if that is consensus I'm actually proposing that and Greg and I were proposing that we should actually look into it and um have people contribute to with the to to put a yellow paper back to up to date so that's why I feel that uh using the arguments that yellow paper is no longer maintained as a way to block links is for one week and for two it doesn't also apply to execution and and and even

longer I don't think deprecated documents um is one thing is a reason to stop uh linking to them like you um for for us we believe that uh giving people historical context is also sometimes useful and so um what we don't really give historical context in the repository that much that's not really the point of the Eep the point of the Eep is to specify and to give rationale for the decisions usually needs to carry historical decisions like his historical context right otherwise how do you make a rationale

of Eeps is to not link to a whole bunch of stuff and if we were to be providing a lot of historical context then we would be having to provide a lot of links to oh there is a discussion here on Twitter then at this interact we had you know this decision it originally was like that like this isn't a uh you know assimilation of a whole bunch of information about how we got to this certain point that's trying to concisely define the spec and trying to concisely Define why things were chosen and summarizing a bunch of conversations but that to me is like not that big point the point is is that the yellow paper isn't updated past the merge there's not really people working on it if that changes then we can reopen the discussion and think about it some more but right now we have three full-time

people working on the execution spec it works post merge it works for Shanghai we have people maintaining it for the foreseeable future if it gets to the point where it's not maintained then we can have a discussion okay this thing is not maintained anymore is this something that we need to keep supporting links for but that's just not where we are today so again I I understand where you're coming from um but I feel and I believe Greg will very strongly that we should allow authors to link and um the fact is we don't if you can get the yellow paper to support Shanghai conversation I don't think yellow paper needs to um yellow paper needs to be updated in

order to be qualified to be uh to be linked that's the point like I'm not arguing with you that yellow paper is out of date that is sad fact we agree that but the fact that we don't allow a LinkedIn to add yellow paper and then the fact that we are not allowing linking to other live clients back uh live clients on implementations I believe that is making it very hard for authors to um to to make their arguments yeah that's separate the yellow paper no no so um I'm saying that restricting we should have very very strong reason to to restrict link unless there is a need rather than we should diff by

default link this permit link without uh unless we have a strong reason and why are people adhere to the yellow paper like what what good does it do to link to a resource that doesn't accurately reflect the current state of ethereum so what's the point of linking to an EIP like what's the point of uh it is to link to to ER T20 to erc721 because these are finalized standards that represent the state of the art it doesn't represent the state of art ERC these things are finalized standards that are accepted you can't link to something and become final if it also is not final

that is not how we Define linked if we begin with it is we're using the proposal EIP proposal to let people make arguments make technical arguments and even like to begin with we there is an RSC that people were following will use must and should and that even that one that RFC is being updated that was that was deplocated and then we linked to it without no without a problem so we're just empowering ourselves too much to restrict link and then again I I know that we're not I'm not going to convince you and then uh you're not going to convince me either and I think that we can put aside so then we should

close this issue because if we're just gonna sit here and like argue about it every single meeting this is not useful like proposals that we to change the ethereum repository the EIP repository should generally be accepted unanimously and if they're not then we just need to move on and start working on next to the next problems all right I'm agreeing that we should allow executions back to be linked and that was what I proposed and we know that yellow paper is being uh being it is not being uh in consensus yet so that's what I proposed we split it out and then we let the execution be permitted to go in and so the yellow

paper we can just wait another six months or a year and then we'd come back to discuss our stats that's fine with me but I think that something needs to material change to discuss again like we have discussed this several times now and nothing is material changed on the front until like I I am not going to be okay with accepting the yellow paper until it supports the latest Fork I reserved my opinion you reserve your opinion and I don't want to talk about this next week or in two weeks or like there's two other possibilities that either there is a material change or um the sentiments in the in a group changes how's that

so my opinion on this is that is there an instance where we are actually severely impacted by not letting uh the reference to yellow paper come in the eips I mean if there is such an instance and we are really being impacted and it is a real impact then it becomes something to discuss about else the discussion is moved the impact is that uh after when they are making uh EIP arguments they want and sometimes need to cite the historical context and then um yellow paper has historically been a very good

source of the of the execution there I think this would be probably a good place to let this discussion settle down on maybe if people are more interested can add more uh like you know support on the pull request itself because hold on I I think I have one question for like clients my client do you think we should permit current link to exact location uh spec or do you think that we should permit live link to execution

link uh spec what is the differentiation link permlink is git uh get uh it is github's link that includes the commit which links to a uh non-changeable um specific snapshot of executive of a of a repository live link links to a relative place of inner repository that may change so do you think that we should allow permlink to execution stack or we should allow live link to executions back let's like I mean we can't talk thank you

link with the permalink right so if you link to a perm link it doesn't change it's gonna be out of date so we're already shooting ourselves in the foot by accepting a resource that's not being updated that's the point you can't like in the world of war links you can't assume the stores is going to be up to date you never will be like yeah that's why that's just like I'm just using this argument to show you that you cannot assume that yeah it's already not up to date like it's not nothing that we have to assume we already know that nobody is currently working on the yellow paper I don't know

if that's ever going to change it probably isn't it's going to be really hard to define the merge in the context of the yellow paper and so why go ahead and accept this thing if the most like it's going to be just become less valuable over time if the execution spec stops being supported at some point that's unfortunate it by by definition by your definition the perm link stops being changed it stops evolving so that that that's exactly the same place where like if you don't think executions back as one thing but as snapshots of each one of the individuals themselves linking to each one of them is going to be out of date no one is maintaining and changing that

print link because it cannot be changed I mean no points to have multiple resources pointing to the same things the execution spec already implements all the historical hard Forks the yellow paper is not being updated we don't need to have two ways of linking to something depending on how you feel or like what resource you're used used to we should be forcing people down this one funnel that's supported right now and if something changes in the future we can address that issue but this is just how things are stand right now I do I don't think you answered my question how could uh how could link to the permlink maintain the the up-to-date status

it doesn't but someone is supposed to come and update it back with the current I think that's how it should work sorry I don't hear that I'm not sure if I follow you no no we first we can't link to a dynamic link because uh Dynamic link can change and the content in the EIP can basically go a very very tangent to what now the dynamic links contains right so so if the and the issue of permalink needs to be resolved by the fact by the matter of updating the AIP itself so I guess you know permanent permanent needs to be

there but the EIP updation also needs to be hap needs to happen if something material changes in the link right what I'm so I'm not arguing with you that we should add live link I'm just saying that the the same reason that we disallow live link and uh the same reason that we disallow yellow paper is going to be the same link that we disallow permalink because permlink don't change it will be out of date no one can change permlink which one really would be what time does I'm arguing I'm arguing that I'm sorry go ahead sorry I I want to say that we I think

the what really matters is what context does yellow paper has that execution specs don't have and people can't refer to I think if we can answer that question then maybe we can make a logical decision about this I agree I I mean don't forget the reason that we're having this debate is because the informational EIP for evium equivalents that we just said we should close was asking for it this is why we're trying to put the yellow paper in for something that we don't even want to support the repo there's a lot of other eaps that has tried to add link to yellow paper like the fact that this come from the

the the the the the context the adding and EVN full of that one I don't think it it really matters there's historically a lot of other eaps that is trying to link to Yellow they let them open a PR to add a link to the YouTube 57 57. sorry what was the the number 5757 the EAP that defines how the app links to the eap1 and then sorry I I I I don't think I I heard your

last sentence I'm saying if people want it then let's close this and wait for someone to come back and say I have this EAP it's really important that I have the link to the yellow paper right now the person who said they want the link to the yellow paper wants to try to define something an informational EIP that we don't think is a good fit for this repository if at this later point an author says it is critical for my EAP that I link to the yellow paper we can have this debate again okay all right if that is uh that is a possible uh new information I would accept that to uh to wait for uh this discussion like I can accept we put this exception on hold until either yellow

paper changes or a number of uh editors who feel that we should allow link to yellow paper changes or there is an author who has um strong reason in their own EIP that needs to allow this it needs to allow this how how's that otherwise we put this discussion in on hold for another 12 months or so there could be another reason there could be another reason when Bart decides to make it stagnant so I hope uh one of the conditions uh come earlier than bought so we can probably bring it back to the agenda yeah I feel like we should

close these things and not just let them sit there because then we get notifications when stagnant that we want to talk it about it again but we've kind of reached this impasse where there isn't really a good way forward and so we should close it and if somebody comes and reopens the pr or decides to open a new PR that does this thing we can have the discussion again sounds good all right um maybe for like another issue that we just another pull request that we just discussed 6269 if someone can maybe close that uh

that would be nice I don't feel comfortable closing it because I'm the one who is very vocally against it so somebody else wants to take care of it I'd appreciate it okay yeah which one I can I can try six two six nine two six nine okay that we decided that it should not be a part of EIP repository and followed by 6306 if we think that we can probably take up this discussion back um to the meeting when we have an example for a proposal who really needs it for 6306 I split it in two so there's one for the yellow paper one for

execution specs now um yeah okay then okay fine then we need to add a comment there maybe for the proposal to know about it and this again will be either closed or will be just one part of it in the pair all right uh so we can probably move on to the next one the next one is a um PR number 6650 and it talks about customizable editors Sam do you want to discuss six three eight six eight three four right now

I'm looking at it um I see okay so this is for yeah so it'll only give editors like it'll only tag editors for certain um keywords or for the lack of certain keywords in um proposals um I don't really feel strongly about this unless we have like a more um rigorous categorization system but uh okay so we are still discussing six six

five zero yeah I don't I don't know if this is ready for um an eipip uh discussion yet yeah right I just wanted to provide background here like you know in the last meeting we asked the proposal like what is the proposal and he probably added a few more context to it like what uh is being tried to be done here I just wanted to let it just know so they can take a look and provide the feedback there is no pull request for this proposal yet okay and I see that uh PR 6 8 3 4 uh is

already there thank you Sam for creating that that is to allow links to the yellow paper as a separate discussion okay fair enough I'm gonna add that in the summary for today's meeting that concludes sorry anyone wants to seriously yeah I I tried it I try to close 69 uh six to nine at six nine I don't have closing uh I don't have closing rights anyone who has covered in the right uh please close it and then I already noticed down our meeting notes to say that we will close it okay thank you thank you for that um Matt maybe if you

can give it a try because Sam wants to be reserved he's like uh vocal about it and he just want to reserve from this so if you can give it a try sometimes today or later it worked yeah okay I have to refresh my agenda so it can reflect it here as well oh yeah it does all right uh the next one is eapw bot issues um Jose if you have any updates to share hello yes I think that I finally managed to get the the code not panicking I already sent a brief summary to you Sam so I'm gonna work in the test Suite this

weekend so when I will get that done I hope so awesome thank you so much cool if there is any other issue of high priority that you would like to take next maybe you can check with some because he generally manages this bot Repository yeah for sure thank you thank you moving on to the next item it is eaps Insight so I have added hack MD for the month of April as well we have four new eaps as draft two promoted to review and two eabs in last call with three eits getting into final status last call

proposals are EAP 6220 with the end date on 18th April and the other one is 6105 with the end date of 4th April which has already passed so the author is requested to create a new pull request if there is no major feedback for aspect changes they can create a new pull request to move this proposal to the final status the three final eips are EAP 4736 that is clwp consensus layer withdrawal protection there are two erc's ERC 5006 rental nft nft user extension and ERC 5219 contract resource request all of them are added

in the hack MD in added to the agenda um that's all on eaps inside for EAP editing hour we had our last meeting yesterday there would be another meeting two weeks from uh yesterday and I have added agenda to the new meeting people may request any pull requests they have question about their particular proposal and that will be answered by um AIP editor Samuelson generally takes out this officer to talk to authors and then last item for today's discussion or maybe information is a action item from the earlier meeting I

have added link to the notes I'm just taking a quick look okay so the first one was related to 5682 no consensus um 6579 was approved office obviously it would have been merged and the third one was uh about this trauman proposal discussion to be continued in the link provided there so probably there is no action item uh specific on anyone so yeah that all concludes uh for the items listed here today anyone has anything to bring up share I want to discuss

I had one thing I wanted to mention here like I mentioned it in the allcard of meeting as well I'm not sure if we have all the proposals for uh shape upgrade in the last call I saw only one proposal in last call and one is already final because that is a meta and that is not going to be deployed but there are I think um three more proposals that needs to go in the last call now we do not have even two weeks it's less than that but um I'm wondering like uh what would be the next step is it okay that someone from Caterers make creatable request or yeah okay fine then I'll go ahead and do that thank you I appreciate it okay uh that's all anyone has anything

else to add for today cool Vince thank you all for joining us today see you in two weeks on April 19th at 1400 UTP yeah bye everyone thank you thanks everyone thank you thank you thank you