EIPIP Meeting 51

Transcript

welcome to eipip meeting 51. i have shared agenda in the chat the first item listed here is a discuss policies to merge pull requests to update an eip in absence of author's approval i have added the uh link which i have taken from the eat rnd discord from sam wilson's conversation actually i was also thinking about it a few days ago working on eip inside i came across some old pull request if i can share and people may refer to it uh the pull request number is 4766 so what i found that the general

recommendation is that the interested parties should folk and create a new proposal and submit the pull request but i was hoping like in exceptional cases like making small edits to final eips do people think that editor should be permitted to merge the pull request with minimal or maybe a no-brainer kind of edits request so what is the general part here in the past i have if it's like just a typo or something like someone just fixing a typo or they're just like maybe it's a very non-contentious like word change like a grammar fix and whatnot pretty much anything that is definitely nothing so nothing normative

can happen to a family at all um that that's just straight up can't do it um if the change is substantial in any way like i can strawman why someone would disagree with it then i usually wait for the author so this includes like uh who it was wanted to go through and change the usage change a bunch of word choice choices throughout all the ieps like i forget what it was think blacklist they wanted to change to something else uh like block lists i think and that is something that i'm unwilling as an editor to override so um again because it's a it's a very political political thing it's not just

a grammar fix like the eip isn't incorrect it's not invalid grammar it's not like a spelling error like this new person is coming in and saying i think this should be worded differently because i have a different worldview or belief system or whatever for those ones i am very much against editors overriding the author um even though they are technically allowed changes like that are non-normative and therefore they're allowed for final eips what was the number for the one that you were referring to puja what was the eap number sorry i was unmute and i was talking

so the number is four seven six six so the only change here is a removal of a semicolon which is which looks like an additional is not needed there sorry this is this is not any a not eap 4766 is it pull request 4766 that's correct uh yeah um oh i see the code code is wrong and does not currently execute yeah i'm fine with merging this one um it's just a non-normative correction that fixes the bug and the example code

normally i so for the first situation like this usually what i'll do is i'll wait a little bit to see if the we can get a hold of one of the authors to get them to approve it just because i prefer to not override the process if it can be avoided um but for something like this it's been a month i'm okay with merging it um without the authors right so i was hoping like if we can come to like you know some suggestion or guideline for this for future eip editors to be referring to just like we have a policy for eip one like it is open for two uh two weeks and it is approved by a couple of editors it can be merged after two weeks even if we do not get all eip editors approval by

that time so for these kind of small changes which are considerably no brainer i mean like i know eip editors are uh educated enough to identify if can be or not and it is approved by them then probably after a month or maybe two weeks time it can be much so just wanted to have some decision on that side um yeah so like i said the main thing that i care about is making it very clear that this would be for grammar and spelling and incredibly trivial changes only any changes that someone might find contentious for any reason i think we should avoid doing so

as long as the wording kind of makes that clear i'm okay with it absolutely i'm also referring to one more pull request and its number is 4513 it looks like this is also a small change in fixing a typo for a function name and that also seems to be like you know i've been done in a while but still hanging out there so if an editor wants to go through and actually review this i am okay with it but um like from that line alone i can't assert that that is not a normative change like someone would need to actually like read the eip and make sure that that this is in fact a correct change to make things better and

not something that makes it incorrect um this gets into the problem of we don't have enough editors to go through and review everything which is why we lean on authors to verify stuff like this all right i think i got your point here i was also looking into one more pull request it's four four one seven i'm sorry i i kind of collected all these numbers which i thought that might use some attention here so about this four four one seven it looks like it was um approved by one of the editors but we haven't received any response from the author and the change seems to be like smaller one and obviously this is like a

longer duration so uh is it fine like proposals like this should be merged um some of it like just removing the white space from the end of lines like that part i'm fine with um i'm guessing they fixed the table rendering for one of these uh yeah again this one's this one's kind of bordering on the this is starting to get to be a fairly large change and as an editor i don't particularly want to read through it at all and determine whether it's valid or not and it's great

if we have authors that can take care of that instead um also none of this is so like the white space changes for example are not necessary like they don't actually change the rendering at all um i'm i'm fine with them but it feels very opinionated and i'm generally apprehensive of making opinionated changes to other people's eips um yeah i think for this one personally i would rather get author approval but also it's an erc so i wouldn't be the one to handle it anyway right so we can leave it up to salmon like lion alex and greg all right um i think i have also added

uh in the later agenda i think it's point number two also that if we can some way automate these things and send reminders i will bring it back when we get into item number two but for item number one i i think uh it is okay to have like grammar or spelling or like trivial changes small trivial changes can be merged after one month of period and once it is approved by some of the eip editors does that sound reasonable like i will obviously i'll try to reword it better and then make the uh suggestion added yeah i would say if if it's been sitting

for a month and it is a trivial grammar or spelling change or typo or um just like very very minor bug like missing semicolon or extra extraneous semicolon some code and it's been sitting for months then yes i'm fine with it um that seems reasonable to me so any at that point any of the editors can override and maybe one day we have a bot that helps with this but i don't know i'm just overwrite i think works all right samuelson do you have any thought on that i mean this is a from the discussion that you initiated on etherendy i mean i'm kind of in the complete opposite

direction as micah i mean i think we should probably like have a formal process for taking over eips and for like assigning new owners and all of that stuff and i but i'm new right like i don't really have i haven't you know battle tested my opinions yet so we'll see how this goes for a while and see what happens yeah i think one thing that we discussed probably before you joined the call uh this is like for exceptional cases especially for the edits related to final eips because i don't think it makes sense that we go ahead and create another eip

uh four can create another pull request for a same eip which is already in final making small changes right well yeah for editorial changes like i think that's the term that greg used for them i think uh yeah it makes sense to let editors merge but like yeah yeah all right and does it need to be updated somewhere on eip1 i i own my and uh maintain a hackmd file where i try to add these exceptional cases for reference of new um eip editors like people who are from the apprenticeship program but do we think that it needs to be updated somewhere on eap one as well eip1 currently says final this ap

represents the final standard a final eip exists in a state of finality and should only be updated to correct errata and non-normative clarifications um i think that's all the text we have on it in eip1 and i'm fine with that as it is all right personally all right then probably i will add it into the hack md file so people and exceptional cases may be able to refer to that thank you i think we have kind of a recommendation ready uh to be added moving on to the item number two unless anyone has anything else to add on item one which i believe did we want to have the longer

discussion sam just brought up aha i mean like i'm open to it like the process change for the entire process change for eip editors overriding are you interested in pitching your thing sam uh i have another call in 10 minutes so i probably wouldn't be able to participate very much in the discussion okay in that case sam i would like to uh straightway come to item number nine which is about a survey for having a new time i know um like i would like to see more iap editors joining this call but looks like the time is not working the best for everyone so i have created a small survey it has only three question one is

uh what would be the best time for you there are a few options you can select from that or maybe you can suggest something that works best for you and uh if in future we would like to rename this meeting the current the current name is eipip and there are a few suggestions if we would like to rename or just go with that i would highly appreciate taking out time and responding to that survey and based on information collected from all ap editors uh maybe we will propose new time for the meeting all right moving on to item number two um number two is uh discuss the possibility of bot replacing the pr description with the standard standardized template i think uh this is

also suggested by sam wilson yep yeah just a lot of authors seem to or or a lot of people making pr's i should say don't replace the um the text of the pr with anything useful they just keep the template there so you know i think um some things that i'd like to see is like a link to the rendered uh eip um maybe a description of the change a little bit just like it just to make it a little bit easier but it's really a low priority thing are you suggesting we have like a bot that handles this or would this be something that we'd request of users hey be done by the bot so like it would just take whatever text the author leaves there uh puts it in like a little

uh like puts it in a specific section and then adds like a header to the the comment oh yeah i'd be totally fine with that if we have a bot for that so i am assuming that this would not be eapv but it would be the general eip bot that we have right an enhancement for that i'm sorry i did catch it so uh this part okay all right okay then maybe uh we'll create an issue for this and see if someone can work on this particular item and uh just for bots enhancement i have added few more items here one is like

what sending reminders to author for action required and what sending reminders for editors to action required so i have few uh pull requests here like for example pr4762 it seems like it has been open for authors response for very long time uh what do people think about having a bot sending reminder after three months because after six months we just send we just make the proposal the pull rick was stagnant and uh it would be nice to have sending a reminder before that and similar thing for the eip authors like i have seen that for example 3975 pull request number 3975 that has a response from the author and

it appears to me like now editors has to take uh action on that but i'm not sure if that is slipped because we have like over 50 pull requests open you provide a link to that eip so it's not the eip it's pull request number three nine seven five yeah can you probably write a link to that of course i can do that she's sharing here in the chat so uh the request here was uh to make some changes and uh like it is to move it to final i'm concerned about this particular eip because um

this would be required for the merge eip because in that i think 3675 this proposal is mentioned and we generally recommend that if a proposal is getting into finance status we make sure that all the proposals which are like required should be in the final status and i'm not sure why this is being blocked for so long if it is just waiting for editor's response so maybe we can send a reminder using bot uh so for this one in particular um i am unwilling to approve it so we're waiting to see if we can get two other editors that disagree with me to approve it and currently matt has approved so we're waiting for someone else

to say yes i'd like this to go through and to prove that eip editing is not actually a dictatorship um my reason is i don't think there should be an eip at all like i think this should be live somewhere else and not be in the eaps repository it's essentially fiber correctly it's consensus spec-ish thing and it's lived in the it's got put in the ap repository because as danny mentioned in discord today it's dumping ground for homeless standards and specifications and i'm very much not a fan of the ips repo being the dumping ground for homeless standards and

specifications but uh if two other editors are up for it um feel free to override me is there a precedent for something like this being merged actually this is an informational category sorry yeah so there there have been precedence for overriding micah yes like there have been eips i've refused to merge because i disagree with their presence at all um and yet other editors agreed that they should go in and so it has that aspect has essence um historically we also have stored lots of stuff in the afp's repo that is not an ethereum technical standard or

at least a core layer technical standard um this one's not even a standard or specification which is also why i don't like it it's just kind of like a description and i really feel like this should be a blog post or a docs documentation site or a readme or something like that somewhere else um not an eip because there's no standard no specification here it's just like hey this is a description kind of ish thing of uh i want to say it's a proof of stake like it's a vague high level it's not it's not sufficiently specific either like it just kind of glosses over some very important parts of how a proof state works and it has you know a thousand external links to a

bunch of other different documents so it's not self-contained like this has everything that i hate about going in when one eip is like one eip that kind of encompasses all the things that i think should not be in an eip um so i have that is why i'm blocking it but again that doesn't mean that all the editors agree and matt has already expressed that he thinks it's fine as an eip and so he's just waiting for one other person um because he feels that if an editor is saying no and another saying yes then we should have a tiebreaker basically and i tend to agree with them and in the inverse situation i do the same thing so if you're if you're up for it sam feel free to take a look at it and uh be

there i am i'm way too new for this i'm not getting involved in a controversial vip also unfortunately we have you greg and alex and we need one of you to get involved in the controversial controversial eip and it's been what is it five months and neither greg nor alex have gotten involved so it's that's why it's kind of sitting here in this really uncomfortable neutral middle ground state because we don't have enough editors to act actually block it and say no this will never go in we don't have enough editors to actually approve it yes this will go in so it just sits here in pr waiting waiting yeah yeah so it it's now going against eip1 so we can definitely delay it for a lot longer so

actually um i think a little different here i mean i may have a little different opinion because this particular proposal is an informational category that can be allowed because informational uh proposal by definition is not a mandate that people needs to follow it's just a piece of information around the protocol development which this proposal is actually trying to provide here in terms of like what was planned with the beacon chain and like how uh people want to uh continue working on the beacon chain and some of these um inspiration has been implemented in the proposal 3675 i believe and at least the terms are being referred to so i think because this comes into a informational category

if editors find it okay to be allowed to be merged as a pull request this would be one of the best informational categories proposal because we are really scarce on informations around the protocol changes in this particular category especially yeah so if you agree the informational category is a reasonable category to have um then this eip does fit that um i've been trying to get the informational category removed from the aps repository for a while yeah i think i think things that go end up in the informational category should really just be like their own web page like or their own doc site or go to ethereum.org

and draft up like a thing there or hackmd article or any number of other places that is not a technical standards um again i'm mostly alone in this like i think greg has spoken out about being generally in favor of informational ips and previously nick was in favor of them i believe um so you wouldn't be going against the grain if you decided to approve this sim you would just be going against micah and you know i really don't care i'm just not going to put my stamp on it that's all yeah i think that that is fair um unfortunately sam has to uh drop off uh but i think the recording will help him follow your uh opinion on this and i am

not an eip editor i cannot definitely approve that so we'll wait for more eip editors to uh chime in uh i was just hoping like uh to look into some of the enhancement features to be added for bot that can that some reminders can be sent out to the eip editors like if that is lost long lost and i think there is another pull request which i believe is created by you the number is 4601 created by mica and yeah this looks like the even the author has approved it but this is waiting because

uh two reviewers have been requested to review and it's pending on that let me take a look um a valid concern um i think it was alex yeah alex said they were against the change um and that's kind of why it stalled out

i think their their argument against it was reasonable and so i'd be very hesitant to override that especially for a final eip all right the reason i found these things to be addressed soon because if you don't do that this will again start piling up and the number of open pull requests would be so much that it would be again the same problem so if we came across these kind of pull requests and we think that it is not good to be proceeded probably we can um can you after the like i can take another look at this and see uh if it's worth keeping open i'll need to sit down and read through the whole

discussion again um if you don't hear from me like in a day or two uh feel free to ping me again about it sure thank you i'll at least try to leave a comment saying what my current thoughts are yeah i think that would be helpful okay so that was it i am not sure like if we have any recommendations suggestions for like creating issues for having this bot sending reminders because i know this is like of the lowest priority if at all we consider this because there are a lot of other open issues that

needs to be addressed before this so maybe i can let it live here come back in future meetings and discuss this again moving on the next item is get sorry i saw you unmuting micah he wanted to add something moving on the next item listed here is github discussion for discussion 2 link i have picked this one from the issue that is there on eip github also from the earlier discussions

regarding this particular issue earlier the uh the issue that was highlighted was fellowship of ethereum magician does not allow to edit the post like author cannot edit the post so i try to reach out some of the maintainers of their website and from what i was communicated by the team there is this field post edit time limit it was then set at a certain number which was greater than zero however uh it is possible by setting it to zero that means uh an author who has some reputation on that forum say tl0 or tl1

they are allowed to edit their post for like unlimited period of time so if an author is really new maybe that would not be working for them but if he or she has certain reputation and they belong to tl0 or tl1 author then they would be able to edit the poster and my understanding is like the team agreed to make it to zero though i cannot say it for sure because i haven't uh verified it so i would appreciate someone looking into it and if there's issues still persistent maybe we can reach out to team does anyone does anyone have a very old

ethereum magician post that they've written that they want to try to edit i don't know if i have any samia i'm not an author of any proposal i proposed many times but it ended up somewhere else and that's okay so maybe if it is fair we can maybe consider that this issue is is uh something that can be taken care of if someone has any challenges editing author stuff then we can definitely reach out to team but but i think it it should be resolved and that should not be a case other than this particular issue do we have any other thing that needs to be addressed for the fellowship of ethereum magician

to be considered as main discussion to link or the place i believe the ability to edit original posts was the primary thing that would like the primary argument that uh was made against using ethereum magicians so i'm currently looking at very magicians and it does not appear that i can edit an old post of mine have you authored that post by any chance yeah yeah so i have a post that i wrote back for instance for eip2718 this is back in june 2020 and i do not see an edit button for it which i assume means that i don't have

the ability to edit okay thank you so much for highlighting that maybe i can go back to the team because i understand from my last conversation the team agreed to make it zero that it should be allowing people to be able to edit it for any period of time okay yeah find out if they actually did that or not i don't i don't see it anywhere or maybe it's not retroactive but i would assume it would be okay yeah i will definitely check on it okay thanks all right um yeah anything more on this topic i'm definitely owning this task to check out

with the team and get this issue resolved but i'm hoping that if this issue is resolved probably we can start promoting fvm as a as a forum for discussion tooling the next item on the agenda is eip's github page renderer has a critical vulnerability i believe micah has pointed out this thing on discord just wondering if this issue is resolved or do you need any resources this is an ongoing issue we don't have anyone um on our team who is a ruby expert or even knows anything about ruby at all and since jekyll is ruby when there's a

vulnerability or we need to do a jekyll update or some or ruby dependency update um none of us know how to do that and none of us have the time to go and figure out how to do that uh not a problem i think we can ask community for help and we may be looking for someone who has knowledge on ruby and if they are willing to come and help on updating the jackal updates here i just wanted to be sure that if this requirement is still open so we shared the word out and try to get someone okay

i'm gonna skip the number five item execution specs uh i know samuelson has to drop off so i'm gonna skip this item numbers sorry i just realized i was talking about the ruby stuff and didn't realize i was muted before the so for the previous one i was restate what i thought i even told you um is an ongoing issue we don't have anyone on the team who knows ruby or has an inclination to learn ruby but jekyll which is the thing that renders the pages and to the eaps.theorem.org is written in ruby and so when we have a vulnerability that we need to address or we need to do an update or something

none of us know how to do that or how to evaluate such an update or how to make sure it works anything like that and so we need somebody who has some amount of knowledge of ruby to help um with that ideally on a recurring basis because it's not the first time this has come up okay we can add that information uh just curious do you think it will help that this piece of code be written in some other language and then be used like we did rewrite the bot eip bot again so do you have any thoughts on that um that would be a pretty large undertaking um

i'd be hesitant to go down that that route um just because i know how um like big and complicated of a task that will end up being it's not impossible but i wouldn't recommend it sounds fair in that case we will continue our search for a ruby expert to look into these issues okay the next item bot issues and eipv issues i know there are a lot of open issues right now and i am looking for more people to join

in to help us get those issue worked on so if someone who is listening to the call would like to contribute to the ethereum eip github repository please take a look at the eip part issues and eipv issues links are available on the agenda the next item is eip's uh insight so in the month of march so far one significant change is merged to eip1 and that is limiting links to external resources

and there are certain wordings that has been changed to eip1 so please take a look at it if you are an author and maybe try to avoid using any external link going forward there are two new proposals which are merged eip-4844 and eip-4863 and only one proposal so far has been moved to stagnant that is eip3326 wallet switch etm chain rpc method um this is just the start of the month so we would be expecting more mergers coming soon um but on this particular proposal micah

if i can ask for your opinion here the proposal number 3326 it looks like it's an interface proposal right and earlier we decided that the process would be different and we may not be continuing 3326 you said that's correct that's the erp's repo uh this looks like it's merged what's the question it is stagnant three three two six eip eight three two two six okay sorry i just have shared the link in the

chat yeah um okay so what's the the issue with the stagnant why is that a problem no that's not a problem uh my question here was like i know most of the eips on the interface level are going to be moved out of it so uh that's it like uh should we start closing it or we should wait for part i think waiting for what would be a good idea right but they die yeah i'm fine with just letting them fall into stagnant eventually um if they're not finalized and if they are finalized i'm okay leaving them there and at some point we may just remove the interface section

from there i know we shouldn't do that yeah i think my preference is to let the bot turn them stagnant eventually if they're not finalized and if they are finalized just leave them there for the time being that's my weak preference but i'm open to arguments against them yeah i think uh in the next six months we would be expecting some major overhaul with this uh eap process so if at all possible taking the advantage of change of the process we can try to add or remove the categories we want to see or we don't want to see in the eaps in future okay that's good and i think we are almost done with all the

uh items now the next one is eip editors apprenticeship meeting yesterday we could not have the meeting and the next meeting is planned on march 22nd number nine is eipip meeting time and name survey i did talk about it in the meeting earlier so if you are an eip editor and you would like an alternate time for this meeting because it would be nice to have all eip editors get synced once in two weeks and close the open issues i i hope that that is going to be helpful for people so if you are open to it please fill out

this small survey for us item number 10 is review action item from previous meetings so from the last meeting it seems there were three action items formal on boarding off for william shaw benville and sam wilson sam has already been added as eip editors and i believe eip1 it's also updated because i remember seeing simple requests to update eip1 but william sharp i have shared the link with him and i'm i'm hopeful that whenever he gets a chance he will he will make that pull request yeah action 50.2 puja will get in touch with

andrew in order to remove eip 1706 from the yellow paper so andrew uh confirmed me this morning that the yellow paper has been updated and i hope that 1706 is removed from the yellow paper now action number three shashank will create an issue to fix the validator check field withdraw reason um i don't see shishang on the call maybe we will check on this issue list if that is created or not if not then i will follow up with him so that's all on the items listed for

eipab meeting 51 anything else anyone would like to bring up today nothing from me it was pretty light today looks like even if the agenda list looks longer but thank you so much for joining and sharing your recommendations for some of the information that i think would be useful for new uh people who are trying to join in as an eib editor thank you everyone for joining the meeting today have a good one everyone thanks puja thanks bye