EIPIP Meeting 105

Transcript

welcome to EIP IP meeting 105 uh this is issue number 337 on eat caters EIP IP GitHub repository on our agenda we have items to uh discuss with respect to open issues and pull request we would like to discuss some of the changes to the final proposals some updates to EIP 1 which has been standing for quite some time and um uh there are uh I think one or two issues that may require some attention other than that I'm curious to hear thoughts about EIP versioning proposal this proposal is uh in the poll request for about 6 months now but uh in the recent days we have received strong

recommendation coming up from the testing team so I would uh love editor's feedback on this uh proposal and if we can perhaps merge this and look into some of the other details that requires editor attention there is a process document shared by Timo recently about allev Network upgrade and E magician process Improvement so if we can collect some feedbacks and thoughts on that that would be nice to have we can perhaps take a look at eips insight for the month of may as well as June yeah so that's all about it let's let's go ahead and begin with the item number one which is edits to final

proposal uh we we are talking about the pr on EIP GitHub repository and the number is 8607 it suggest a change to proposal 2982 EIP 2982 to fix table um yeah but surprisingly I don't find an error when I look that EIP on e. ethereum.org I wonder if anyone can see it differently and if there is an error can we merg this PR I can take a look and uh I think it's okay if if they actually say display sure we

should I think he has just ared the header and uh I don't think that I think that the rendering might not be an issue at all so there could be no actual issue may maybe the person just trying to get in a contribution uh but even that the Val uh uh I think the CI is not passing so unless he can fix other things in that particular e e to make CI pass we won't be able to merge it anyway right that was my uh fear in the first place that when I look into that EIP it seems perfectly all right and table is rendering just perfect so I

wasn't sure like what this pull request is all about very well um I don't know if it yeah it seems it's it's rendering correctly this one doesn't add Merit then in that case we might want to close the pr maybe try rendering it in uh uh in the GitHub itself maybe there is some issue over there I don't know it would be nice like uh someone can maybe review and if that seems to be not adding value to the existing um EIP which is already in final status we may perhaps want to close that bull

request very well um the next one is uh on the EIP GitHub repository and the pr number is 8590 so um this seems like we have received a two editor comment here one says that it can be merged and another one says that it cannot be merged um I I wonder what people think do we need to create a call for input for this to make sure that we have all editors on board yeah please share your thoughts I mean it's only adding uh the fork time to uh to a value which was dbd which should not have been in the first case

when it was uh sort of move to review as but at least at the final call so I mean I'm okay with this I don't see a problem there were many uh previous core eips that's the if they specify Fork number it was left TBD until very long it seems common um we don't have a I don't think we currently have very stct way to track uh to like we we didn't make it a strict rule to enforce this uh as far as I can remember but I'm also okay for this to be merged into it I don't have strong

objection if an EIP is going into final there should be no TBD I agree yeah we can perhaps make it a point like whenever anything is moving from last call to final proposal there should not be any TBD either you remove that section entirely if you do not have any um final value to be added there or else we should have a number very well it seems like uh Victor is also not uh uh opposing U merging the pr uh we can perhaps uh like maybe check with Sam as well if he has any strong

opinion otherwise this pull request can be merged so we can wait for another week or I we need to check with Matt because is's the one who sort of proposed it right okay so we'll keep it open for another meeting or if we can get any um answer from Matt I will try to check it async uh on our Discord we'll Marge it otherwise we'll bring it up in the next meeting the next one is a PR number 8390 which is for fixing EIP 2 it's a kind of a fixed reference

test it seems like a um the authors who may perhaps approve or or like confirm the changes they are not around I remember a few years ago we had this discussion like what do we do with the PO requests for which we do not have author around the general idea was to merge it with editor permission like editors can overwrite uh the author's permission here but there was no um timeline defined like after how long what we were practicing in those days were like keep it open for about a month and if we do not hear from the author and editors strongly feel that this can

be merged there is no problem in merging that they can perhaps override and merge um I wonder what uh editors on board here think about it and can we maybe we add one sentence defining the timeline about how long should we keep this kind of proposal open when editors are fine merging them okay call for Action that's a good suggestion we can do that but in general what are your thoughts like maybe we can keep it open

for a month does that four weeks timeline sounds okay for any PR to be open where editors are um fine merging them and we do not hear from author okay cool cool so we can perhaps create a call for input for that one the next one is um an update to EIP 1 I'm not very sure about the user also who has added some comments at the bottom so uh just wondering if that user seems to be a Spam and definitely spam all right and there's some bilingual jokes but if you speak Spanish

it's definitely spam it's kind of a de nut comment very well and this PLL request seems to have but yeah comments in the SP yeah yeah the pr is not the PRC seems to have received quite a lot of Thumbs Up and I remember seeing some tweets around that as well it seems people are generally on board uh is there anything specific that we are waiting for or can it be Force smsh fine with me I'm not waiting for anything I think um I think Sam already approved it I don't know yeah what it's waiting for

I'm not sure if uh someone can maybe try closing and opening the issue it may merge this proposal directly if not then I will bring it to the next uh editing office hour to check with Sam requ two more reviews so I can approve it and then yeah okay I think one of the either Victor or Matt needs to approve it as well sry which one 8247 a243 okay yeah I was uh approving the previous one they just need another approval okay I need to take a look it seems

like very well so it's just approving issues uh looks like for that one uh if someone can approve and it gets merged fair enough if not then we'll bring it to the next office hour to make sure it is has much the next one I approved it and I think one more approval would be needed thank you uh Victor if you get a chance please take a look and if you find it uh okay then maybe it can be merged automatically the next one is a PR 8503 it seems to be a pull request by Sam Wilson to update EIP 1 for eest I think eels test Els is the specification that

they are building around execution client um to me it seems like it is just waiting on um editors approval so if editors can maybe take a look at this one as well the pr number is 8503 I'm not sure if this is defined anywhere but it should have been uh maybe IP 1 changes requires more than three editors approval cool yeah I think so so I approved it as well so maybe two more on

edit yeah and I don't think Sam would be able to because he is the author of this one so we might want to look for other editors on call okay cool thank you Victor so Victor and match Victor has already approved so we'll check with Matt for all of these if he can approve them the next one is a miscellaneous issue and the issue is okay fine I'm not sure what uh proposer wants to do over here it doesn't seems like it is added with some of the pull request if it is a general question which the author uh which the user could not find a good place to write the

question to receive an answer this could be one or else it could be a Spam one are we talking about a610 that's right the person says they are not able to Pro to create well yeah this seems unclear like what is the question here what kind of response he's expecting maybe someone can take a look

and if this seems like an spam definitely the next comment seems like an spam here it's in different language so sort of a technical qu mhm that he wants to do some signing and across chain and I don't know what he wants it to happen in certain way my view is this should be post on the on the E ether scan uh ethereum magici this is a technical discussion and this the way how they it is not the best way to generate the proper discussion if they cannot do it I can help crops cross poost it I don't fully

understand what they meant but yeah I don't think anyone is blocked from using ethereum magici that's right maybe we can um add a comment over here to uh check with the user if he has any specific query with respect to like changing chains um with respect to EAP 712 and if he can maybe start a conversation at FM yeah it sounds to me like something specific to like metamask or VM or some the the the question isn't even a question that I think the authors of EIP 712 could answer it's like something more mundane about implementation while

or browser implementation right in any case I think Victor is right that they're it is very weird to post here because you can't figure out the discourse uh plug it you know identity system eth magicians is pretty easy to set up an account I mean I guess I haven't done it recently but I wonder what they meant about not being able to post there all right all right so we can just drop a comment for the user and U you will take it from there if he or she may find any issue creating account we can perhaps help getting that done

very well uh we do not see any call for input this week Ah that's great surprisingly this is the first week as far as I can remember that there is no call for input uh so let's move on to the next uh section for the agenda and that is other discussions and updates from the past meetings so in one of the earlier meetings we talked about EIP versioning proposal um I think I have added the link uh to the poll request that is eight is 034 this EAP was proposed back in December 2023 it seems we had quite a lot of conversation and discussion on Fellowship of ethereum magician and these people are very much willing to

get the proposal merge in like you know in draft so they can use this number start talking about it and recently in today's euf meeting and also in earlier EF meetings um testing team team showed great support of the versioning scheme for eips the questions that they are wondering are like can we add this change log section to EIP template in like Preble section and who should be the best person to update this change log like can it be the author can it be the editor they want this thing to exist in order to make sure the test cases

they are developing are with respect to a specific EIP and they would be uh following it easily if the change log number is changed so they know that their spec is not up to date and they can perhaps update that I wonder what editors think about it and can we merge this proposal so editor opinion on my side editorial opinion is that this kind of proposal should be able to merge as a draft and as a proposal to generate more discussion um because it's um it's a policy discussion uh my governance comment on this is that I'm

generally in favor of supporting versioning and uh upgradeability like Improvement on EIP and erc's the hard part is about defining who gets to own the newer version who gets to decide which newer version is the canonical one there's definitely going to be cases where there's a base version that say EIP EIP 712 as an example and there will be different opinions and how they would be it extended so I think in um in our uh Juan Bumble is here so he has experience ietf

um I well how iatf works is that they create this kind of they Define this kind of working group and working group owns the current and future rfc's under that working group and the ietf has governance process to Define which ERC uh which rfcs for under the uh the the care of which working group and and how to start a working group um currently it's hard so I think this the this the governance of this um meta proposal should be uh surfaced to the working group to the uh road map that uh project you also proposed to should be included in that

kind of discussion otherwise it it it is going to be hard to to do within uh the current setup so in some quick summary um editorially I am in favor of merging it so that people can discuss on the governing govern side I don't know how to do it I think it needs to be included in the working group and road map discussion of so just to be clear is the proposal saying that while the EIP is in review it can have multiple versions I don't understand because once the EIP is final there is just single

conical version because it's talking about standard RBS that is correct the idea here is to uh like when client goes for implementation they come up with different spec changes so keep track of these spec changes they want to version it in terms of major minor and patch and there are further discussions around like what they would like to capture according to them major should be any breaking changes to specification minor could be anything in addition to specification but does not require changing and existing implementation and Patch could be like something cosmetic if we are doing for example I mean even

I was engaged in this conversation for example here like if a proposal is uh under draft or review and they are being considered for an next Network upgrade client can go ahead and Implement that with one spec but if there is any minor spec change or major spec change that is not possible to be tracked because we do not have versioning and testing team are not aware of that so this particular proposal will be able to provide them U that visibility and once the proposal is final it is fun then we do not expect any change but in case of any cosmetic change say for example we receive some typo error so we can perhaps change the

number of patch it is in terms of x x doy doz so we can perhaps keep on changing of the number of patch and testing team does not have to do anything with that but for General people they would know that this proposal may have received some changes I'm sorry wasn't my audio very clear no no it came good it came through good well sorry yeah yeah so that's the idea here I mean I think my my opinion on this is that we shouldn't be doing anything because for example if we look at uh the defet proc right so how it moves is that at some

particular D Target you have some particular spec that is already outlined and uh the spec team can just uh link the ELP with the particular Comet hash right so it doesn't really change anything I I think it only increases the bookkeeping and uh is unnecessary in my opinion because more things you ask people to keep hard the process will be yeah I I I kind of agree I I've been thinking this whole time that um like with C suspects sometimes we do commit

specific links uh if something's changing um and you know there's commit specific links were just added from um you that uh the E1 PR to add Casa links uh part perhaps because we started that precedent of using them internally to refer back to like you know uh but be sometimes when a when there's major changes to a spec a cape before final we say before this commit the syntax was totally different so old implementations older than that may have like whatever um so yeah I mean I I would

also say that since it's already happening on GitHub maybe GitHub is good enough uh or or simpler to Peg to testing I would say that if if this were added um it could be maybe like optional front matter so that if um an EIP just totally wants to ignore it they just can and and if someone messes it up it doesn't throw a wrench in the whole thing like I I feel like if you make it loadbearing and then someone forgets to bump the version or bumps a y instead of a z when they're just fixing a typo then it creates this whole governance thing because you were assuming they were

always accurate like if you made it sort of a optional informational s thing it might be really useful to some working groups or semi IPS and then the rest could ignore it I don't know that sounds like a good suggestion like for example we have a an optional Preamble field where we add the EIP number as like you know required eips for the proposal it's not for all of the proposal but for certain proposals which are kind of enhancement on any existing one they use this field so if uh protocol uh upgrade texting team is requesting for this kind of specs

editors may consider it for uh as an optional field and this may or may not be needed for say for example erc's or rips it can be used as needed otherwise we can define a default value that can be used for example U 7 EIP 71200 so no changes nothing like that we can start with a default value and only for the proposals which may require this kind of changes spec changes can use that I wonder k uh do you think it is uh still adding too much on authors or editors to maybe keep a track off yeah I mean given editors won't be

able to take a call on all the proposals whether it is a minor version or a major version or a patch version change right and uh but again we can defer it to the EIP authors for that but or maybe optional can work but again uh in terms of practicality I actually see I mean it's it's basically easy for someone just to clone the repo and attach a tag to it and use that tag to circulate it um so I'm I'm not really sure basically but like if if this is just to

be for people who are doing Dev work on the tiip I mean they they can track it in better mechanisms and actually for example what I mentioned earlier was that people would want to look at some particular definite spec rather than at some particular version because that is what they are targeting to uh Dev with other teams thank you uh Victor do you have anything to add on this one I don't um I think it's up for the

community to decide um whether they want it I I just I think it's okay to merge into it and then also um I would personally suggest them to make it informational rather than meta but other than that it should be okay to at least ask um yeah all right so I think we had three basic questions here number one can this be merged today it seems like there is no strong objection on merging this one um number two can change lock section be added to Preamble like it can be added as a preamble um optional but that would require again EIP template change which we will bring it in the in the next

meeting and the third question was like who will Who will be owning this uh change log update it's uh it's very much convincing that editors may not be able to make a decision on that so it has to be on the author if he or she decides to uh change the log I mean update the log uh one thing uh just quickly to respond to Victor I don't think it can be an informational it has to be a meta because if we are adding it in Preamble that needs to change the template as well and that can only be done on if it is something to be followed by all proposals but as an optional field it would be again optional for the proposal to include or not include this

particular field in a proposal if it needs to be add to this uh Preamble I agree it must be mattera um I think actually adding it to the Preamble could be a separate meta U proposal rather than proposing this versioning schema I think the version versional schema could start as an informational and every EIP author who wants to do it can just specify it within their own the body of that EIP nobody can can disagree with them that there's aversion in their own body um once more we see more adoption I think we can put them

into the um into the Preamble um I would be a little bit worry about prematurely adding Preamble for this pratice before it becomes widely adopted sounds good to me and thank you for merging the proposal we can perhaps have further discussion on allord meeting and try to collect some uh feedbacks from client development team as well as testing team I'm hoping them to be there as well on the call to maybe um share their point of view and that would U generate the status change for this uh proposal very well well at least now

these guys will have an EIP number so they can start talking about it with different teams thank you for marching it moving on the thank you moving on the next one is um a proposal change uh we will briefly discussed this in the last EIP IP meeting it seems that uh in naota uh there was some some discussion around the EIP IP meeting the processes around eips and how some of the network upgrade process can be uh improved um I know this Fellowship of ethereum magician thread includes process Improvement

around multiple aspects I'll be curious uh to maybe hear thoughts on the network upgrade process specifically um if I remember correctly yes so uh there is uh this proposal of aligning EIP with respect to network upgrade proposal uh process so I'm curious what people think about integration in particular and yeah in general if people have any thought on this particular um set of pro process improvements we can take it and maybe if requires like longer discussion can be a part of upcoming uh meetings agenda item I mean people can add the feedback

asnc as well here I wanted to bring it up in EIP meeting because I think if it is for process Improvement we might want to implement some of these proposals or may want to discuss it so yeah if it is too early we can perhaps discuss it in the next meeting very well um the next is eips insight and uh monthly eips status reporting so uh I think the dashboard is uh up till May uh but the eips um inside.com provides information for June as well as the

hackmd uh provides the information for the month of June it seems like we have only um two proposals added as draft both are ERC and I think there is one more but the the schul is updating this dashboard once in 24 hours so we might want to take a look into that um and we have received one proposal which is an interface proposal it's EIP 5792 wallet call Api the last call for um last call deadline is June 26 if uh anyone interested to add any feedback

comment to this proposal please feel free to do so um you can always is drop a comment on Fellowship of ethereum magician and yeah it would be nice to see the proposal moving forward so that's on eabs insight and uh after that I think I have added a link to the agenda for EIP editing office our meeting number 38 people can also watch the recording for meeting 37 and just quickly taking a look at the notes from the last meeting wow most of them are now

closed all right um I don't see any open action item pending for anyone and Sam is not here so we should be hoping to hear about working RP chatter in in the next meeting or whenever he's around that's pretty much covered the agenda for today uh if anyone has anything else to maybe add or propose for the upcoming meeting well thank you everyone for joining us today and uh I look forward to see you in the next meeting two weeks from now thank you