EIPIP Meeting 92

Transcript

welcome to EIP IP meeting 92 on agenda we have uh some items to be discussed some open issues and uh then we will get into some pull requests which are open but they are with respect to final EIP so we will perhaps get some solution and thoughts from EIP editors whether to merge that or close the PRS we will have discussions from the past meeting which will also include the EIP ercd post then we'll have eaps inside followed by editing office hour and review action items from the past meeting so um here the first item is topic group uh since past few meetings

we have been discussing about the split of EIP ERC repo and currently this is in work in progress I know in the last meeting we discussed about having a meeting of EIP editors to discuss more about it um Panda if you would like to briefly update us where we are on that and if we have that meeting what are we planning to take care of so that meeting so there's a few things one uh the EIP review bar is not in a state that can be kind of like like no changes to accommodate the split will be able to be made but or will be a to be merg into actual split repositories by the in days additionally there's not additionally we

can't do the website updates on our own we have to actually get some people from the ethereum.org team in order to do that as such really the only thing things we can do during that meeting are actually split the repositories and transfer a bunch of Port requests just to be clear for U you mentioned about we might want to have some ethereum.org team member to take care of certain things I think we can have that there is a participant I don't see him on the call today but he was in the last call um if you want we can extend the invite to him and if any

support from e.org team will be needed we can perhaps take care of that sure uh we have a calender invite uh Greg would you mind uh actually in this ORD dming me or Sam uh just just your email address so that we can for on the invitation to you I had to find my mute button and I have a mouth full of Apple an invitation to what I'm sorry this is the meeting in seven days where we are going to be

doing the actual repository split itself none of the CI because the CI isn't in a place where we can do the split and we're not we're probably not going to be doing any of the website related stuff for uh because we need someone to actually do the configuration stuff and what would be my job the job would just kind of I I guess the reason we're having uh like just like I imagine there's probably some debate as to well we want this one in the erc's no we want this one in the eips and so kind of just like the more more people there uh actually I guess

the more people there the more discussion there's going to be but like the fairer the discussion would be I'm so tired of this discussion I kind of agree like there is definitely basically working basically working hard to do something I never wanted to do in the first place I am inclined to agree all I could do was try to reduce the damage um I am I'm inclined to agree with you here but it's being done okay we're talking next week we're talking uh next week EIP time kind of Wednesday at 9 Central

time that would be 10 eastern time like I don't know is it 14 U UTC yeah okay so 14 UTC why don't I just say no rather than than saying maybe and saying no in the end anyway okay I'm I'm hammered we we we've got our seed funding and we're trying to work every waking hour yeah we've got fing for what uh for for a startup um oh cool ethereum is only at the edges we take ethereum and payment but internally it's

it's nothing much to do so um cool good luck and so I'm busy trying to build a very secure VM that can run python um Good Luck Sam is probably giggling anyway yeah so in terms of actually stuff that would need to be done for the split the list is quite long considering that there is also this request to split the website which I'm still very firmly against and would veto if I felt that that veto would actually

do anything too why in God's name split the websites yeah um I think I if I remember correctly like I'm sorry if I am misrepresenting your Viewpoint here but the argument here is that um one it might be a little bit more work to make it happen considering the repositories themselves will be split there might be a bit more and it and the argument is also that the user experience would be better uh because you don't actually have to sift through any of the not any of the eips that you

don't care about which I find to be an extraordinarily odd argument because you don't have to do that anyway if you just use the search functionality that's already available in my Rewritten version of the website which like did not accept for admittedly somewhat Fair reasons although those reasons are now outdated because V press is now in a stable release by the way for anyone that

doesn't know what my Rewritten website is would you mind if I just shared a link to it in the uh chat okay here we go come on so there there we are it's just the's website but ritten in V press so that it looks a prettier and B loads faster and C uh is actually in a status that we can actually develop uh develop on which the Jaco website uh currently nobody know nobody knows how to completely like like

if we needed to add an entirely new plugin I don't think any of any of us have like like none of us are Ruby experts um I am the closest one to being able to make major changes to the Jaco website but even then like I'm not able to make that big that that big of changes and that also kind of goes into another problem with what splitting the website would entail and that's that well there's nobody to maintain the eips side of the website they need to find someone to learn probably an entirely new language I guess

there sorry what POS what possible objection is there to this I really don't know I wish my client was here what I mean what do they want to split from what they want to have eips ethereum.org and erc's ethereum.org huh we have six panels here and they don't like one of them is is anyone here in having two websites and if so would you

mind speaking up all I'm in favor of having two website not because I want to have EIP and erc's showing up on two website I generally am in favor of competing of like having people of um ACT people have access to to different approach to see uh we to C EIP and so I want erc's and eips to show all of them that that's possible with just one website though I can I can easily change I can easily just change the layout file

or create a different layout file that changes depending on whether or not if files in the erc's repository or the iip's repository this is at this would require about 10 lines of code would would anyone like me to go ahead and get the framework there so that so that we can have a kind of uh I guess repository dependent uh layouts I think you're kind of debating

a ghost St right now because like is Matt wants to yeah do the split so I think we can just table this until the actual meeting we have with Matt next week and then yep we can Hammer all this out then because I don't think we're going to make any progress on it without Matt here I I guess can we move on to number 273 the deadlines passed and everyone has voted yes doesn't that mean that the Forum has now been reduced to the three yeses and it passes um yeah so yeah so we're going to stop talking about erc's and eips for now um

and then 273 is the next open thing uh we have one two yep so yeah this one we can close everybody who's everybody who has said something on it has agreed with it so we can close it um the actual po request implemented I think was already merged so it's kind of pointless uh so 274 let's take a look at that one so this is renumber EIP 5000 all right so you have vote [Music] no okay ah this is a fun one this is the uh ring the EIP

so um does anybody have anything they want to add on renumbering EIP 5000 before we stop talking about it forever uh well I mean there's no consensus yet so it's not clo so it's not closed the deadline's passed but that just means the quum is reduced to the number of active uh people and there's two yeses and two NOS so we don't need unanimous right that's kind of the whole point of having the keeper of consensus yeah we don't need unanimous but we do need consensus and the people of consensus can only decide when consensus has been reached it evidently hasn't because it's tied it's tied on votes right so we have

two for ring one against and then Victor you're in support of REM ring and then I'm in support of remembering so I mean I if nobody else has anything to add here I would say that this like we we would merge it um so I'm just going to reiterate kind of summarize the points kind of I believe that are for and against it for ruming it's that it kind of sets the precedent that if you find a loophole that like allows you to do something like reum a

you're EIP does something nice or like any other loophole that you get to kind of abuse it um it also I guess kind of make makes editors look bad for like accepting what could be considered uh some form of like preferential treatment the arguments against reing and I am again against reing is one it wasn't actually against EIP 1 at the time uh two um yes and to uh the correct thing to do in response to something like this is to

modify E1 to prevent anything similar from happening in the future um would you say would everyone here say that that's an accurate categorization of bre point I think that's reasonable yeah does anyone have anything to add I guess I have one thing to add to the no and that's that we can't set the precedent that um rules can be changed retroactively which I think we I think

we should set the precent that if something is okay at the time it's done we can't just subsequently be like oh that doesn't feel right we can't have that and punish kind of punish someone for something that was totally okay when they did it was was anyone swayed by either Point um I'm still in favor of

ring I'm still against reing all right with um no other comments assuming nobody else wants to make them and the comments on the PO request being the latest I will go ahead and merge that PO request well it's still tied 33 there is no consensus here 3 three yeah we've got um we've got you voting yes re number we've got me voting no we've got like

time uh voting no MH um we've got uh Victor voting hold on vo yes we've got I totally butchered his name probably voting no that's 33 I didn't think they were so we are we are considering editors voting here only right yeah oh well then we have you you yes me no uh is uh is G11 uh governing or not he is anit

odius yes but is he a governing editor or not basically does he have voting power oh yeah there's that whole debate um where do we land on that I think we land I think we landed that that anyone well the intent was that anyone in the governance section of the EIP editors. yml file has a vote all right so does it mean that like we recently had votings for who can be editors so whoever are selected in that list and continues to serve as an editor should have this governance power like

governing power and his vote his or her vote should be counted so so I think there's kind of either two ways of like there's two ways of doing this the reason why the EIP review bot can merge po request can merge PO requests is that I delegated it the power to do so um the config file itself is just a representation of of who has the power to do what and in in and of itself IP review bot delegates some of its power to the people in that file um and so I guess we can work

backwards and say that therefore anyone in the governance section is an editor anyone that's not is for the purposes of the EIP 1 definition of editor not an editor and for the purposes of are they really an editor yeah they're an editor so it's confusing and probably should be made more clear I agree to that I think for the time being if people are open to accept this concept perhaps what we can do is apart from Bots let's talk about human here whoever are listed as EIP editor in EIP 1 should be considered for voting and their like you know their opinion

should be m for at least for this call for input process in place is my suggestion here I don't know what other people think so the it is up in the air whether or not people that are in the government section or not in the government section can vote because for one thing we had all those call for inotes for editor removals at the uh Sam opened and one argument be made that when people were voted either kind of yes or no to having them remove P when when it was voted no they aren't removed as editor that kind of implies that they

are an editor according to the Charter and therefore can vote the other argument is they can't actually have any effect on whether or not uh PRS that modify a living near such as EIP 1 uh are merged or not the intent when the intent at least according to like client that when uh Victor was brought on as an editor uh was that he couldn't have a vote I don't know if that's still the case I would argue that he should have a

vote he has clearly demonstrated that he is a very competent very engaged member of the EIP project and prob and almost certainly deserves a vote in fact everyone in the EIP editors. yml file I believe deserves vote yeah I think everybody listed on E one should be the the set of editors like that's the only thing that works for me I mean I guess I guess the best thing to do here is create a call for input that that's for hey let's define let's define kind of an EIP

editor as well let's let's Define the initial set of EIP editors right that have voting power and from there we can use the editor ad removal CFI process to keep that list up to dat but just so that we're on the same page as to what the initial list of editors is I mean again you can't there were all there were all those um there were all those cfis for editor removals that you opened yeah everybody survived so I think uh yeah everyone survived but more to the point uh even like client voted no let's not remove uh Victor as an editor which

strongly implies that Victor was an editor and Still Remains an editor yes so I I've been operating under the assumption that E1 is our governance document um and and the editors listed there are the editors but uh yeah there's there are I think I think we should continue um like as long as possible to have that as governance document and it is listed in the e one is I mean are editors the one caveat here was which I understand is like they may or may not have permission to merge the poll request that is I think a separate topic we can perhaps

talk about it but as long as governance is involved especially if we talk about Victor's case the only thing for him was that he would not be maybe actively involved for core eips but other than core eips he was definitely involved in every other set of e interface um nwork except he's not listed in the governance section uh the Erp editors the yml file um and I'm because that's maybe because you know we do not have a specific uh emerging power for ERC as of now but I hope that would be fixed when we have we do we do actually have a

separate section for merging uh erc's versus interface versus networking versus core versus informational versus meta there is actually very fine grain detail and Erp review B for this stuff can we can we have respective PR Victor maybe we can have that and let's see where we are now I know things were different in the past but a lot have changed in uh over a period of 2 three months okay for the purposes of this meeting let's just consider all the all the editors in ip1 to be voting editors in that case wouldn't the pr to to rumber EIP

5000 uh either it would be 43 in favor of ring or 3 three tied either way I'd say arguably there is not the rough consensus needed for the uh keeper of consensus to determine that consensus has been reached why do you say that because there's about just under half of people that disagree with it that's not consensus by any stretch of the imagination oh like rough consensus it can be right what what is the definition for rough consensus here because I thought

that rough consensus was like okay there's a there's a few objections but but we need to get this merged anyway even though that there are some OB objections we can sort them out later not half of people actually just don't want this and they strongly opposed to it uh so I can read it here so working groups make decisions through ref basically process I basically I didn't think that the keeper of consensus had the power to determine what consensus was that that is their o well I thought it was to determine when consensus has been reached so I think it is there for a

reason like all editors are putting their faith in the keeper of consensus so whatever decision at the end is made um should be acceptable by the group at the same time definitely there should be a valid reason for going ahead with it like the decision making rough consensus could be like you know even if uh it's like kind of very closed eye or not all of the editors may have voted so there are some gray area that we are giving permission to the keeper of okay consensus to maybe take a decision there okay just one quick thing before we we merge IP the EIP 5000 R PR you're aware that this effectively does set the

precedent that we can retroactively change ip1 right like say like say okay that is B basically even though that was allowed then it's no longer allowed because that is the precedent that's set here yeah I think the the precedent that I'm okay setting is that the EAP editors can do whatever the hell they want whenever they want but these are generally the rules we're going to follow that to me doesn't seem well that is kind of not the president I'd like to set but okay yeah I mean um I know my vote does

not count here but what I meant to say here is like um e editors can or should do the numbering thing before the pr is mar as draft I I kind of um agree with the the pr is already yeah so the EIP is already merged with the EIP number 5,000 yeah kind of late for that maybe we can have this Pro yeah please go ahead I mean I guess the best thing we can do is wait for it to go stagnant and I mean my I I'm kind of of the opinion that if like at some point

we should start deleting St IPS right they're still they will still remain in the git history but we don't need say threeyear old stagnant eips in the repository and still being published um and I feel like we should set a threshold for that and then problems like this will just go away once once they go to stagnant and then they go to because the authors of EIP th have simply gone a wall they're not maintaining it they're quite that's AE proposal

right that's a what that's a core proposal right oh I sorry couldn't catch the core or core yeah yeah core um yeah I'm just wondering if that proposal is an active pursuant anymore or not I quite frankly I think it's I mean considering that no progress has been made on it I'm not I'm kind of not in favor of renumbering but in but I'm actually starting to get in favor of just deleting it just because like well deleting it once it reaches stagnant they they the EIP process

shouldn't be too hard for them to just submit another EIP so basically uh do we accept kind of a on once the proposal stagnates then it gets deleted as kind of a compromise no okay no deleting IPS even stagnant ones delete from repo or just not display on the rendered version uh

actually delete from the repository but it remains in the get history I think that would not be fair to many authors um because getting stagnant is a status people can bring back they can resurrect if we start deleting they will lose this opportunity okay how about this though the since all of these eips are still in the git history why don't we it's therefore possible to verify as verify whether or not some a particular proposal was stagnant or not that doesn't mean we need to actually

keep all the Stag stagnant eips actually in the repository we just need to have it possible have it have a kind of a workflow for stagnant eips to be brought back from stagnant but I don't think we need to have the EIP number there for still reserved we just need to kind of have have a process to bring those VIPs back I think this is a little off topic from whether we're remembering agreed yeah this is like way off topic we should get back for today's like know propal I'll create a proposal um but yes can can we therefore agree

that there's not actually like okay I guess I guess we have different definitions of rough consensus my my interpretation of what rough consensus meant was that okay it like like we kind of like there there might be some opposition to certain parts of it but it's still not too dissimilar from what we originally had which was anyone can veto it instead now it's any anyone can kind of like raise objections and once the keep of consensus has determined that those objections have

been kind of sufficiently dealt with um do you feel like your objections have been heard I guess is the important part here I feel that my objections have been heard but I don't feel that they've been completely understood like I I feel like I feel like the implications of like the we can just do whatever the heck we want haven't been completely thought out because like I I will say like for core EIP wise the reason that there are core eips is because EIP process is considered to be at the very somewhat fair that the that the editors are bound by a certain set of guidelines that they have to accept

proposals and that like basically that there is kind of a certain degree of legitimacy that is kind of earned by not doing whatever the heck we want and so that's kind of why I feel like we should not set the precedent that we can do whatever the heck we want I do I I I hear what you're saying and I think I understand what you're saying um and I think we should Endeavor to be the most fair and and just that we can um would you say that that given that the rules were what

they were at the time it is fair to kind of change an e number even though there was nothing that was technically done that was wrong at the time sure sure there was controversy and now we would consider it if it happened today to be wrong and probably worthy of reing but at the time it wasn't against the rules so why are we wasting time on this what's done is done just let it go and move on what has been done a number got

assigned to a document yeah and never got assigned to a document so what well I mean the the the argument for ring I'm sorry I'm sorry I I've heard the arguments they go around and around that it wasn't against the rules when it happened it wasn't a big deal changing the number just is more confusion is taking a lot of our time um we spent more time arguing about numbers than anything else well the reason the reason why we are currently debating it is because Sam feels like consensus has been reached and I do not feel the consensus has been

reached well now that Greg has said something I feel the consensus is going the other way yeah I slept really badly last night so I'm I'm slowly waking up to what the issue is on this one so we are now generally with it so Greg your opinion is that we leave it as EIP 5000 yeah just who so now we are tied 44 so I'm just going to we we've spoken way too long on this I am saying officially as keeper of consensus that we are closing the poort request

consensus is to not change it okay all right with that uh we can move on to the next number that is 275 most of them s suggested yes and the deadline has passed me I both reiterate why I think it's I I mean I I say yes because it meets requirements has set forth inp 75757 I'm sorry I think I just missed

can you please repeat it meets the requirements for an acceptable Source like I get that like Cent says it's not been updated for several forks and that bringing it up to date post mode would be a huge effort that doesn't change the fact that it is free it's a free source and commits are immutable and therefore this meets the requirements to be accepted ma would you like to maybe just confirm or if you have other thoughts uh sorry I'm just updating my

notes here give me one second the problem is that again white kind is the only one that's saying no here and he it's not on the meeting and the date has passed that's uh one other important thing here so whatever thoughts and like voting has been collected should be again the deadline only set Bas the deadline is only there to make sure that things will eventually pass basically that if someone most likely act SI if we're going to be totally honest at the moment uh doesn't actually vote on something that it's not held up until say Alex or whoever um doesn't

vote starts to vote on Greg should we allow links to the yellow paper yes or no yes okay I would say there's a strong enough consensus I guess Victor links to yellow paper uh strong in favor okay that seems pretty strong consensus all right so we can close it by marking it yes and then next one is number 276 I'm sharing the link right here in the chat oh I added 275 command V6 okay so uh this is for 484 web3 URLs

updating EIP 4804 so what happens when the Quorum gets reduced to zero editors that's a good question we did not receive any input in this one oh because the Quorum is now zero editor oh that was the uh 4804 um Let me let me develop an opinion on this quickly so we shall we have um shall we have a a a different between consensus

yes consensus no a third kind of status which is no consensus and we will table this until certain time I think it's important to keep issue that's literally just keeping the issue open I think there is a respective PR for this particular case we can let the pr be there and get stagnant if no one is coming up in strong favor or strong against especially from the EIP editors communities for this particular topic wait hold on this is just adding an EIP why does this require consensus

again yeah I think because that is uh oh is a final final Final EIP yeah no it's adding a new EIP yeah uh so the the EIP that that PO request used to be editing an EIP and they changed it to adding a new EIP so this doesn't require consensus anymore no not anymore okay we just doesn't require consensus right yeah just just close that call for inut it is fun we are at least reaching on decision and moving faster the last one here is uh active actually 283 that was opened yesterday

it's about accidental function in ERC 223 I see that there are already some inputs there want to discuss or have thoughts here wow is my chat yes it is um I was the one that opened it um or rather opens the pr um so basically uh when reviewing the adding kind of adding erc223 as an actual EIP it used to just be a GitHub issue and not a real e uh I've noted that effectively there was this function standard that was just out of scope of the IP is erc223 is a standard for kind

of a bet a standard that is designed to address some of the problems that erc20 has and one of the functions that erc223 originally had was standard to kind of differentiate between whether or not the token was an20 token or an erc223 token because otherwise they might look somewhat similar I said that that that was out of scope for the uh EIP because well it's not an inter ability e and you can just use one of the other ones available like 165 or uh Victor's e EIP for

interoperability and uh dexan agreed because it is in fact out of skp for the EIP in a later PR dexin kind of I I either mistakenly included the function again or forgot kind of forgot that it was removed or I I guess the pr itself kind of suggested that like he had a slight misunderstanding as to what my objection actually was and it got put into that into the EIP again the EIP became final but with the actual function that should have been removed still there and

so my PR is suggest remove the function that's out of scope and not sufficiently defined because it it it says identifier I'm using air quotes because identifier is not defined anywhere only that the identifier for erc223 is some strain so it can be it can be used sometimes to detect whether or not something is erc223 it it is an odd standard but I could see it being its only IP but it does not

belong in erc223 I guess the question is anyone opposed to this uh we still have some time to uh collect inputs from other editors whoever not whoever have not uh submitted their response here I see Sam Panda Victor and gajendra Singh have already added their thoughts um gin um sorry Greg you have any thoughts on this one um no not really or not

yet all right so the deadline date is November 16th uh I know there are more editors Matt AAC and Greg they have not added um if anyone has any thought perhaps they can go ahead and add it the issue number here is 283 so Greg do I confirm that you're abstaining I think we can wait till the end of the date if it does not come back we can consider that as yeah abstaining Greg you said that you don't care right

so that's an abstain I just want to make sure that we have as many votes as we can whether or not there're for or against again this deadline thing is is was more designed as a in case like an editor just is not available and is not designed to be the default thing we're we're trying to the default should be everybody just gives their opinion as soon as possible and we can move on and that that's why I'm asking Greg whether

or not he's abstaining or not I mean this was just open yesterday so we can perhaps give some time for people to like get the idea realize the concept and uh yeah in in case we do not hear back from Craig and others by the next meeting we can see where we are or before the deadline totally uh got the concept of having a deadline deadline definitely helps us move past an issue giving sufficient time for people to come back with their for and against argument I think we are running out of the time

today so let's try to move fast a little bit I have listed up a few open pull request next which are the um you know PRS to final eips if anyone have thought on it like um the first one is the pr number 7866 which is changing EIP 573 it says that it is a type of fix anyone objects to that no it it is in fact a typo fix so we are good with that merging oh all of these are just fixing

typos that where people have misspelled overwritten apparently yes so we can perhaps take a look and close at least all these PRS we have a lot number of open PRS these days this one's for Lifetime thank you uh whoever has opened all these PRS for submitting these PRS feel like Bots doing this it does feel like bot's doing this I am absolutely fine if Bots do this however this is constructive there was one time oh wow

so many different persons submitting uh rep of typo change yeah I'm almost certain these are Bots but that's fine they are completely valid uh suggestions and deserve to be approved so whoever whoever made these Bots I think yeah that's thank you I am in favor of having bot fixing this is uh and and I thought there was one person who submitt a very long list of uh typo fix of a lot of VIP and I suggest them to split them up into different ones the concerning part here so I'm generally in

favor of that the concerning part is that I notice that types fixing are coming from different GitHub accounts did you they could be fing I noticed that too they could be farming I I quite quite frankly that's skubs from not ours um um they become our they become our contributor they do become they do become they have the first one there there is that a problem though I'm not sure actually it could yeah it could in in future like unless that is a significant contribution just

a typo contribution could make them look like a contributor and can be you know potential scammer or something like that I'm not saying that this person or this bot is actually but that is a possibility so we we don't have any evidence this apart from the fact that the PRS were submitted close to each other by different user accounts with the same uh with the same title which definitely doesn't look good but again this is kind of anecdotal evidence and doesn't actually so these are Bas these are all kind of valid things and I'm pretty sure that like

again this is actually kind of the contributions we want right these are exactly the kind of contributions we want people to do and also if they're if they're kind of doing CI for us is that necessarily a bad thing I could suggest one thing here is like maybe checking out the GitHub account of these resources like if that is completely empty then it could be a bot and could be possible scammer but if they are not just like for example I'm looking at 7840 I don't know uh yeah and it sounds like they are genuine not kind of

so I'm looking at sh86 they actually have the P request shark uh badge and so to me this definitely looks like a bot that has probably just submitted a bunch of typo fixes I let's see can I get the actual web view for this please well we are running out of time I would like to get this thing U you know under radar of e editors maybe they can take a look and respond all right so hopefully those

those will be merge Auto merge if not and if manual merge will be required we can bring it back um uh I know there are lot many other discussion point which we could not be able to take today I'm just curious about one uh action item or decisions from the past meeting about superseding comment um Panda did you get a chance to maybe take a look into it I suppose the decision was that you would be coming up with some pull request for that um oh yes that um I can't remember did I come up did I make the poll request or not I'm pretty sure I did if in case you did yeah in case you did not or even if you did it would be

nice to have it uh added to the agenda for the next meeting we can perhaps take it uh in the next one because we are out of time to discuss it here any final comments thoughts from people they would like to share it today I mean yeah the IP split meeting is going to be in a week um I'm interested to see how this goes that's absolutely and I will DM you the uh email address of the resource from ethereum.org if you would like to invite him for the meeting if you think it is needed then only I will share the details with you well everyone on this

meeting has disagreed with splitting the website now or have at least determined that there is a better alternative available I see your point okay in that case we'll wait till the result coming up from the uh meeting plan on next Wednesday at 1400 UTC by EIP editors well thank you all for joining us today hope to see you around have a good one everyone thank you very much