EIPIP Meeting 17

Transcript

hello and welcome to eipip meeting number 17. um this is the one on september 23rd 2020 and we're gonna get started with the first agenda item and if everybody can get on mute i think i hear just the tiniest bit of background noise um all right next up um our first step we have the eip status abandoned versus withdrawn discussion that's um an issue in the eips repo um uh alex bergzazzi axic opened this up um and i doesn't even want volunteer to kind of

go over [Music] what the um if there was a decision made from this i kind of had trouble following it only because there's a discussion that's in here in this eip issue and then there was a discussion on the eips discord channel in the ieth r d discord server um and i think james you were talking mostly with alex on this one and micah a little bit right yep cool can you like the latest on it because i thought that there was some resolution sorta yeah it's uh mostly a resolution or i can uh the update is the so we we've had these statuses we

over a period of months discussed them and then kind of settled and said okay let's do this uh alex brought in this addition of having a status feel having an additional field on withdrawn eips or abandoned whatever the term was that we wanted to go with that showed the reasoning for withdrawn so he made a pr to have this field be added to the withdrawn vips which that's all good which and then it turned into a a stagnant is withdrawn and abandoned

discussion all over again where we had a lot of back and forth about why we would do either and um we could i do the i can of course relay sort of my thoughts on it but i don't think that's really the the the more important thing is i don't think we should open up it back up to be if if alex and i are going back and forth and then we make a decision in the discord we have then ignored the contributions of all the other people who have been part of this without opening it back up to everyone to be then be a part of it again and that's just a lot more time than i

think is needed at this point so the what we had decided last meeting was to do the statuses as is and do a pr to eip1 because we felt like we were ready and the and how to fit in alex's pr into that is that we do add the status field or at least let's we could let's discuss and decide this today about adding the status field to withdrawn and if that's something we decide on then great and if we still launch the statuses as is with stagnant being a status um and we can always deprecate

uh stagnant if it's not working how we want and move it into withdrawn like alex is suggesting a minor correction just for clarity uh the reason field is the way you're referring to yes thank you i knew i was not getting the right word so the reason the reason field for withdrawn great and mike i saw that you commented in the eip's channel and the etherndy discord that um that we can go forward to with the yeah like exactly like james said with the original um that um given when when you were able to uh could go in and with maybe the help of other

people go through and change um some of the header text um i think that could be scripted right just to change stuff yeah the alex's suggestion is not lossy compared to the current select suggestion and vice versa so we can easily convert between one and the other without much difficulty just like a find and replace or a little script or whatever it wouldn't be hard cool um other comments on this um i i have um you know i was looking into it and i have kind of and i'll propose something i do not want to go over it right now

like if we are okay with going with whatever we decided in earlier meetings and then as micah suggested i am okay uh doing the pr later on but if we have like five minutes if i can get just five minutes i would like to just uh run through why uh clarity on this is important because i was also looking into uh the uh document of exec uh where uh where the proposed process of withdrawn is there where he is recommending that we should be adding a um you know reasons field i am totally fine with that but is it a good time to just uh screenshot um

i think i i want to put one more point out just real quick and then and then let's get started with your with your piece of this that'd be great um the thing i wanted to put out is do we have a right now is eip1 up to date where it needs to be i i didn't find a pr that did the right statuses okay it's not so we need to do that first um sometime okay who volunteers to do that so in the last meeting uh i and james were supposed to get it done we decided to do it but there was this thing that one point uh i was stuck i also mentioned it to james on withdrawn and

a stagnant for withdrawn the condition is this proposal can never be resurrected but when it is a stagnant the the thing is the proposal can be resurrected so it cannot be one or the other field they have to be two different things and that's what i was trying to explain in the proposal that i added in the full request that exit has created oh so if we do the change then if we do a subsequent change based on axis suggestion that's going to make things resurrectable is that what you're saying uh yes according to execs uh um drawing that he is suggesting

withdrawn can also go back to draft okay uh if i made this green share uh yeah yeah and feel free to go through on your on your um discussion on this i think i'm reading your comment right now a little bit and it looks like um it's pretty thorough so yeah feel free to go over it so uh it's my screen yes it's sharing okay so if we look into this idea uh this is coming from execs eip overhaul of uh the document that he has and this is the proposed process so in this process if we look into this

idea draft candidate review everything is fine but when we look into this withdrawn status it can go back to draft but when an eip is withdrawn in my uh in my according to my understanding it cannot go back please correct me if i am not understanding it properly that is the basic difference between withdrawn and stagnant that that was the intention but it would be good to to get clarity from the group if and all of us be on in sync on that idea right so uh i would like to just uh take everybody here i'll take just five minutes to

come why why i'm proposing that i know it's too late to propose that i'm fine if it does not go through in this time and will go later on but just wanted to let people know so when we are talking about eips this thing i think i have shared it earlier as well uh this is the current process that we are following in this rejected is basically the um coming going to the hard fork network coordination part so it's not a part but that was there in the previous one what we are changing here is uh the status accepted it cannot be here uh in the new process uh so this is what we agreed upon last time idea draft review living stagnant

and then withdrawn so withdrawn here means it cannot be pulled back but it withdrawn the status that i understand is something that is given by an author if he wants to willingly withdraw his proposal but what for the proposal that is not fit that is not fit to move to the next state then that is also going to get deprecated that is going to be terminated so withdrawn i'm not sure if this is a good place here where all these thing can go so i came up with this this basic thing is this particular thing is what we have right now idea draft and everything abundant slash stagnant because they

both mean the same thing that means it was left by an author but somebody can pick it up and bring it back to the review status and then we can start moving this proposal forward withdrawn i try to put it here somewhere so a pro a proposal can take it back but what happens to those eips though they have to be deprecated they cannot be moved along so i i moved on to the this next proposal then withdrawn should not be a status it's just a reason why eip is moving into the deprecated or a terminal state this leaves us with this put this process in which nothing is added except

for a review state that means whatever we are having right now is there we just removed the accepted status which should be part of network upgrade and we added a review state which everybody agrees to that that should be there for a longer period to get that proposal reviewed and uh okay fine this is the network upgrade process i was just trying to combine them together so the network process that is coming from the james project port cfi cfi approved and everything else uh try to add the ad status here and then how we are gonna join these two things

like core eip process and network upgrade process they have to be linked so uh this is a proposal i mean this is my my uh that this is the way this can be linked together uh so yeah i mean that is all about why i am proposing just to be not i mean withdrawn and abundant cannot be one thing because abundant can be resurrected withdrawn cannot be okay thanks for all this work this is really good um i would say if you go back to slide seven um or is it a it's eight sorry if you go back to slide eight um oh by the way

brent cfi stands for um oh wait until for inclusion considered for inclusion which is like the new efi not that it's new it's the new terminology for efi right oh great thank you i i figured it was that but wanted to make sure yeah so for this one um i think so this is one of the two process iterations you've proposed right right got it okay i like the second one better because there's less arrows um and i think that makes it a little more clear however i do like the fact that there's a separation between stagnant oh no abandoned means stagnant

that's right that's right okay so but there isn't a withdrawn so withdrawn would be with an abandon right no withdrawn will not be within abandon it will be with deprecated and here is the reason so i have mentioned these three reasons uh one would be author's choice that would be considered as withdrawn number two could be no activity over a period of two to three years because generally i mean i have seen that proposal takes about a year to go into next stage so if it is uh not moving for two to three years that can be moved to deprecate it and the third reason which is very obvious fail to move to next step up because of any of the technical impossibility or something is not right

there so whatever reason we consider this to uh you know stop working on that proposal i'm suggesting this because i was trying to achieve these two goals the number one goal is close the pr spending for a very long time right that is our idea of having these uh these things redefined and work on it and the other thing is we want to have the correct list of eips that are actually valid and people may be working on it so that is the thing that i think that uh adding a reason field as exec suggested would help but i am still not convinced that we should have withdrawn as a separate status i find that as a reason for

closing a pull request okay i'm coming around to that personally um but i want to hear what others have to think what others think about this whole deal what is the argument for having it so certain eips cannot go back to draft like i mean from a theoretical standpoint you can always just create a copy of it so you can always get it back to draft it's just whether it'll have a new number or not what is the reason for not allowing that number to be resumed later for with with drawn for anything for any reason that the eip is abandoned withdrawn whatever the reason is

why disallow it too there would be there would have to be some intervention as to basically there could be some intervention into the authors section and other pieces of when it was so you'd have to go in and completely change the header file and you would have to somehow reflect that there was an original idea from an original author at a different date than was that then was taken and then created with a new author at a new date but still put pull back or point back to the previous and i don't know how to do that cleanly yeah so so sorry sorry i i definitely agree that no one should be able to change the

author on the ip except for the author i firmly believe that and i agree fully um i guess for me the if an author two years later wants to change the authorship or decides to resurrect it why should we stop them like why would we not want to allow that that is allowed that is allowed in the case of abandon and in the case of abandoned the original author may give permission to another champion to take his proposal forward and that's what we do uh uh say for the example of one zero five seven uh this the original author has allowed greg to take it forward so he is bringing in the meeting and he is actually now added as

an author to that proposal so that is allowed in the case of abandon but not in the case of withdrawal why not allow that in the case of deprecated like what what is what do we gain by disallowing an author in two to three years to show up and say like oh i totally forgot about this but so-and-so reminded me at a meeting yesterday they want to champion it i'm going to change authorship like why are we requiring in that case they start over from scratch the so the example i would use is 25 25 the lock rewards um vip so i'm i am intending to have that be withdrawn and the if someone was to res so and there i don't i think it's

me and i think it's just me and someone else is the author so i guess if we sat down and and undid it but i would definitely not want someone else to resurrect the eip and somehow me be tied to it yeah sure and that's that's why you know i definitely even if it's just even if it's the same number but somehow i'm not an author i like that still uh bringing it like the nuances of that i'm not technically an author but the number is the thing will just totally get lost yeah like i said i think that if someone is an author no one should be able to take that away from them like if you want to make a

clone of the ib go for it you're now the author of that clone but you cannot take like aap1234 if i author that i will always be the author unless i hand that over like there's no no one has the right to steal that authorship from me or transfer that off on my behalf the situation i'm considering is like so in your example you don't want any anyone to take over your ip you want it to go away in which case you can make it go away by just simply not giving anyone rights to it so you would mark it withdrawn it would go into the the trash bin basically where it would sit forever because you will never give rights to anybody else to take it over the situation i'm wondering about is if you decide in a year or two you change your mind like you know what

there really was a good idea i want someone to take this over why why why are we stopping you like why does the ifp editors have to stop you from doing that like what do we gain from preventing you from doing that as the author i think you get a little bit more clarity for people um i think you're adding an extra line or you're adding an extra arrow but you are not so i guess you're resurrecting from a band and just to go over your proposal micah it would be you can resurrect from abandon and you can resurrect from withdrawn or actually you can resurrect from anything but rejected right anything but final basically right

go to this slide can you do that so it would be so currently you can go back from stagnant and with in micah's case you could also go back from withdrawn yeah exactly and and if we go with alex's thing those two would just be one circle basically there's also the idea that hmm so i guess someone could come up with a competing eip in the future with an eip that's been withdrawn and then someone could just resurrect a really old eip which would to some people say oh this person had precedent on the standard and it's maybe like

it would have the illusion of either being further along or more official to the average eye in my opinion and so if we're optimizing for the common person looking at eips and wondering how they go i feel like withdrawn by definition comes with more of a finality to people and so if it gets resurrected then i don't know how we reflect in the eip that at one time it was withdrawn so your goal i'm sorry just to make sure i understand that correctly the goal with the finale is with permanency is specifically permanently you want finality to things you want a state that cannot be undone um just for the sake

that it cannot be undone so people can rely on it not being undone okay yes it's because there's i think there's edge cases we're not thinking of number one and number two it would make it easier um and make it easier to have um and have a little more maybe another arrow or another line but it would um have finality yeah i think that's that's the best way to put it were you saying puja so i was wondering like if stagnant and abandoned both can be resurrected why do have two why not have just one i mean like if we look into the exceptional uh statuses that is mentioned in the eip1 it says that author or new champion wishing to pursue this aip can can ask for changing it to draft so if

we are giving the permission even with the withdrawn either why to have the status will be drawn in the first place let it be abandoned i believe that's alex's entire argument is that these two statuses are very very similar the only difference is how it got there so that which is like the reason field and so if but i think alex is under the assumption that we do not want the statuses to have different finality like one one is final one is not or not final bad word here but it's uh permanent yeah and i i would there is there's just kind of weird stuff that happens with cloud on numbers being lower um there and and things not being final

like like imagine the the the resolution that would be for the community if a if something like prague powell went to withdrawn and then they knew it couldn't come back because once it's in that state someone would have to make a new proposal and start over even if even if it's the same technically text it's still a new number which means you need to get everybody on board with it separately and and having this having some kind of finality for the community around some of these ones i've is and where where we can i think i think for me this conversation

has really cleared things up i think the real discussion here is do we want finality in the ips or not i think that i was missing that in all the previous discussions yeah like i agreed with alex previously that those two circles should be the same because i did not realize they had different finality constraints with them having different constraints then i understand why we have two separate statuses um i'm on the fence whether i agree with the finality being a desirable feature or not um but this whole conversation makes a whole lot more sense now or the whole debate rather i think finality would give us more clarity if we actually need two different statuses or not because if that is not there and it can be resurrected i think the present model

is sufficient enough so i have a question on this slide so it says abandoned and deprecated i thought uh the current proposal was stagnant withdrawn yeah fine yeah that's fine i mean i put abandoned to make it very closer to whatever it is right now uh current proposal but it can be stagnant i mean there's no issue with that okay i was confused by that also deprecated just kind of implies that it's been superseded as in something's already been it's already been accepted and final and then it moved deprecated once something else yeah i was not liking the word deprecated either what was the what was the was the word withdrawn was that it was

rejected originally originally it was rejected uh we can use that term like we need something to you know even link that if we want to use the real term the rejected one here we can remove the deprecated and that's how we can connect the core process core eip process as well as network upgrade process yes rejected and then reason field got it okay so now that i'm caught up with what we're actually debating here i apologize for being so slow and oh thank you for thank you for clarifying getting to the heart of it so i appreciate it um so now that now i understand that what what exactly would be allowed to go to final never resurrectable and what is

resurrectable what is the conditions for each i just don't remember what they were oh so for never as a rectangle sorry are you asking for on puja's proposal or on the eip the statuses on seven uh let's start with the one that we currently all agree on supposedly so i know what i'm agreed to so go back to number seven so in this case final and withdrawn would be have finality okay so a thing can go to with like who is allowed to move something to withdraw editors or authors authors

okay so editors cannot move something with trump well without authorization authors for the bot because the bot would go to stagnant oh oh and this i'm sorry i didn't even yeah we're on the different slide okay yeah you're right and so with that that would be done by an author okay so an author can withdraw sorry i was going to say i think if we want finality there should be some official role that moves things from stagnant to withdrawn at some point because we don't want to have someone with eep 2 3 4 have their ebit stagnant for five years and then decide they want to resurrect it and put something completely different in there it seems like after two to three years of being stagnant it's okay to move into withdrawn

hmm can you go over that one more time i don't think i caught everything so here in the reason i have mentioned like if there is no activity over two or three years uh this flex uh okay fine this model provides flexibility even to bot as well as author and the editor so when an editor chooses to move any proposal or the bot chooses to move any proposal because it has not been active for a very long period they can move it to a suppose rejected not duplicated move it to reject it there but um if an editor or a bot choose to move any proposal to withdrawn

i don't think that would be acceptable like in this case if this withdrawn is done by a bot or an editor i i'm not sure if editor would find the editor would be comfortable with that because withdrawn is something when an editor asks i have mentioned this in this example like for one of the recent eipz2583 i think this was of martin and he mentioned in one of the meeting i need this to be withdrawn so he wants it to be withdrawn this has to be closed now this pull request has to be closed as soon as possible because when we say withdrawn that means no other champion can take it forward right so that can be done with the author's request

but if it is done by bot i don't think that is possible if we are interested in having withdrawn represent finalization i don't understand why an editor or a bot can't move eeps to that set stage because it seems like you're not always going to have the author around to vocalize if it's okay to move to withdrawn and it seems like the reason we want finality is to avoid the cases where you have a low number eep that they kind of decide they want to resurrect later on to give them more social credibility for their proposal and is it going to solve having them like have to actually say to move to withdraw isn't going to solve that problem

the can you go back up to number seven what was i going to say uh so if if you allow an eip editor to move it from withdrawn from stagnant to withdrawn that becomes a political decision uh about whether or not it should be i don't see why it's political it can unless we've done something like a certain number of years and then yeah i think that's that's yeah so that right there is just is enough for me to say because to me the reason we won final finality is not because we don't want the author to ever come back to their

eaves and that's kind of what stagnant already is the author ever wants to come back to eat they can like get started again but if we want withdrawn to be a thing that avoids authors coming like far down farther down the line and trying to resurrect it and have a low number to do something maybe different than what they had originally proposed or to have more credibility against the competing proposal that's something that they're unlikely to have you know actively asked to be put to withdraw and so to avoid those scenarios which seems to all hope to be the whole reason we have find the finality of the status we need to have some official way of doing that i think it can be done in a non-political way just saying after two years in stagnant we're going to move everything's withdrawn yeah i think i think as long as it's

algorithmic like something that a bot could do i mean whether it's a bot that actually does the task or a human that does the task i don't care about as long as the decision making is algorithmic so if that algorithm is just this many years since the last touch or whatever and that's algorithmic whether i do click the button or above this button don't care but i do agree that as an editor i would not want to ever put something into withdrawn that was not algorithmic i would not want to be in a position where i have to decide eh i don't like to say eip like i'm going to put pow in withdrawn because i don't like it or i'm going to put eth2 spec and with drugs i don't like it like i do not want to be in that position ever i think this is compatible with how we

just about how we have it then um besides the combining so just to kind of go over right what we have right now for the eip that's going in with puja and james what we have is stagnant withdrawn and we have slide seven what we we have right now right yes okay and then slide nine is the proposal and with slide nine or is a proposal and with slide nine we have abandoned and stagnant still and then deprecated separate but some people are saying let's combine the two am i right i was but that was before i understood

what we were actually arguing about i do not know if alex understands what we're agreeing about i did not get that from our conversation but maybe he knows and i just didn't pick it up so i want to speak on his behalf okay so alex is the one that still is probably it could be in favor of that before we explain what we talked about in this meeting so that's to be determined yeah and so the thing we're mostly agreeing on is the reason field i think we're all there with the reason field we're not entirely there with what the names are going to be but that's not too hard so for instance like if we're going to keep it deprecated or rejected like that's one thing

and i think we should just go with the names we decided on like a couple months ago so just stagnant and withdraw i think that'd be the simplest because then we'd have to discuss like the names for the like the new names and we already had a discussion for the names previously and and nine and seven are actually pre are are actually the same diagram with one extra arrow are they daryl from to so if if deprecated and rejected was

withdrawn then there's an arrow from draft to withdrawn where i just said if you want to go straight from draft to withdrawn you can go through stagnant or you can just go straight there oh you're right it's an invisible it's an invisible arrow it's really there in practice but not in the drawing okay so we just need to add an arrow between draft and withdrawn for the current eip going in however that arrow might be removed pending the finality argument the and then the other arrow is from review to withdrawn and i just implied that if if something goes through you can either go to stagnant

and withdrawn or you can go review to withdrawn because that's just a lot more arrows so that it's actually the same diagram which is different names and are you saying like in practice you can technically you know pr segment and immediately prior to withdrawn and you just save save a step and not yeah you can go straight from with review to withdrawn and [Music] not have to have it go like through stagnant in the in the first place yeah i like that i think when we start defining withdrawn the problem will be highlighted here because when we define the term withdrawn we mentioned that this is an act by an author when he decides that the peer cannot move any further right

but according to the present diagram that we are considering here withdrawn is something that can be done by a bar by an editor and not specifically by an author as well as if something moves on from stagnant to withdrawn nobody would i mean i'm not sure if author is gonna like it that way until we have that justified uh the reasoning field there so the problem comes in my mind comes when we start defining the terms withdrawn um so the the withdrawn being of a state with finality that an author puts

into i'm i'm uh on board with having some two-year two-three-year algorithmic way of of an of an editor also going to that status um the if do we do we want to have in the extra arrows or do we want to just say that something can go straight from draft to withdrawn i think the heroes would help add clarity i think so too i think things can go from draft to withdrawn they can also go from with review to withdrawn yeah so i can i can edit uh it's pretty easy to add to this diagram so i'll go back to the heck md and add in the

extra arrows and not have them be implied okay great i think i believe so i think the one other thing different between seven and nine and nine has superseded which i am actually pretty against as i believe i mentioned in the past yeah and we uh we also we we kind of decided we to go with micah on that from my memory yeah does anyone want superseded i'm sorry are they missing the reason of not having superseded politics yeah politics and also there is a proposal to put a new section and an eip called errata

and and that's and in that section that's where we would define if it is superseded as a technicality i get it i i think i read it uh somewhere on mika's comment um sorry i messed up on that part i got it no problem um okay we're almost there i feel it uh so i'll add the i'll add the arrows so it's not implied and that will help with clarity and now we just need to decide on the names or go with edson's suggestion on doing the names from before and i think it's okay um i have a minor preference for abandon

for that last circle because it doesn't imply um whether it was voluntary or not yeah like if someone can abandon something on purpose like i can abandon my child on purpose or a child can become abandoned not because the parent did it on purpose but because uh they died or something like yeah i i would agree if there is an algorithmic way and a author's choice way to get to that that status with finality then it should not then withdrawn isn't clear so having it be abandoned and then give a reasoning field so an author can say reason withdrawn that's what confuses me when we say it's

about abandoned abandoned means the stagnant itself so the this definition of abandon is not what we're going to go with okay so where we just yeah using abandon as a word in english i think it means exactly what we want if we ignore any previous context we had with that word okay yes okay either we keep it at withdrawn or we change it to abandoned if we're gonna have it be or maybe we just keep it at withdrawn and then do a proposal for having an algorithmic way to get to withdrawn and at that same time we have it be

we then add it to abandon because if if an author can is the only one that can choose for it to go then withdrawn's the best word if either an author or a bot can get there then withdraw no longer is the best word in my mind it should be flexible it should be with author with the editor as well as bot because that's going to help us resolve the issue of closing ps also if if a bot can move it to withdrawn the author can choose not to go to withdrawn by taking some action to so that it's not stagnant slash abandon so he still has that option but

it just kind of makes it more official and doesn't let it stay stagnant forever you're saying that like during that two-year period the author could have shown up and claimed the ap right right and he can he will definitely know that if i don't do something before this two-year deadline it's going to be moved withdrawn and that's implicitly communicating to other everyone that you are going to withdraw that whereas if he wants to do it then he has to put up or shut up basically withdrawn by default um a practical case of where this interaction

would was would have happened is 1559 had at least six months of no one working on it early last year before the like in between vitalik's work and vulcanize picking it up it would have gone to stagnant uh but when it was resurrected it would have gone back to draft and working again and in that case keeping the same eip and the authors and all that stuff totally makes sense it wouldn't have made sense to redo everything but it also hadn't been two to three years and uh i at this point we either we either go with this with the word withdrawn or we change the

word withdrawn is what it seems like so that depends upon how we want to define withdrawn here again so if we if we are explicitly mentioning it that it is something that has to be done by author only and bots and editor cannot do it then i don't think withdrawn is the suitable word here we might want to look something else and my recommendation would not be going with abundant here because abundant and you know because we have a context of that with the present eip1 it has high chances of confusing people because abandoned we are using in place of a stagnant

we tried to rename that with stagnant so people might want to i would so the i don't think anyone actually understands the original definitions from the eip1 either um so us using the term just correctly i don't see a problem and and the that technically the old version of abandon is now stag is is what is considered stagnant it's just stuff that i don't think that uh i don't think will cause any any issue of confusion it's just better language to be accurate about it i feel strongly about that there should

be an algorithmic mechanism for moving something to finally dead uh i feel weakly about naming that thing abandoned i think and it's between abandoned and withdrawn right is there a third thing you're really dead i swear never coming back um so okay so i think i like withdrawn better because withdrawn seems purposeful whereas abandon so wait withdrawn seems more algorithmic abandon seems less algorithmic in my mind when i just like look at the words yes i could the opposite oh really huh yeah it's just obviously for me as well i'm sorry you're surprised it's fine i don't care that right now

oh yeah i got it what was that um i was gonna say i'm i also would think of it as the opposite but i've also maybe this just means we go withdrawn and then and then if if it if it doesn't fit then we update the we just update the language and stop worrying about it in this meeting renaming this easy later yeah now let's do renaming next meeting after more discussion but make sure we point that out in the eip whatever comes of it so whatever so we have the eip going in that james and puja is doing and then the next eip that we put in that changes the status that gives the reason field that's when we would rename it

is that is that accurate or or the the mica doing a proposal about an algorithm and make an algorithmic way to go to withdrawn yeah that could be it too so there's plenty of opportunities to change in the future that sounds good yeah all right let's i guess let's move on to the next stuff um there's not even any steps yeah highlight just what the bullet points are the takeaways here are just to make sure i understand or walk away with sure oh you want bullet points or you said there are bullet points uh i would just like to someone to say what we just agreed to just to make sure i didn't miss something i think i get it but i want to make sure we're on the same page i can say it if what i think is the case i believe we

all agree that withdrawn will have a reason field right yep and yes there will be no superseded yep and withdrawn will be final that number is no longer reusable yep and the one point i'm not sure on will is withdrawn author only or author and that algorithm to be determined future algorithm at the moment i'd let's do so i say we do author only right now and then write a proposal to add the algorithmic part and then let's figure out the timing and stuff and have that be that's everything okay so so at the

moment withdrawn is author only but maybe in the future we'll do something different yeah and i would also support that i just want to i just that's something i think we want to sit down and talk about about what the timeline and stuff is so i think it would be good to have a proposal for that yeah it'd be cleaner if we had an eip before the discussions because right now we're juggling so many things in our head yeah that'd be good anybody else i'll go ahead and new arrows between review and draft to withdraw or not until the future discussion no that would those arrows would go in yeah yeah the arrows between draft and withdrawn and review and withdrawn would go in okay i'm good move on

all right network upgrade repository and the process um this will be an update from james i think uh we have we have it and it seems to be working i have a question about it someone mentioned and some pr that i'm forgetting because i looked at way too many yesterday that there was a little bit of or maybe it was just a discussion in general but um i had with someone where they said on the network upgrade process is it required that there be eips in that network upgrade process i know which one this is and i think it's because

the discussion was around there's a danny ryan put in a specification for eth 2.0 um well okay depending on how you view it it's a specification or not but it was an eip pr that for serenity phase zero and it went through and it didn't give anything on implementation it pointed to um different repositories that had the specifications in them so because it did that there was a little bit of confusion if it should be an informational eip or not and one of the arguments said well whenever they merge or whenever eth1 goes into a shard of eth2

or an execution environment or however they end up doing it right now i think the plan is to have it via its own shard when that happens will that require an eip or will that be something that happens and then subsequent changes would require an eip so i guess the question is in order for that eventual merge to happen or not i'm using word merge for lack of a better word but when that when that is to happen will that require an eip for it to go into the planning phase outside of the eip's repo i it sounds like we're talking about specs any 2.0 specs will someday need to merge

that's the crux of the issue and i don't know if these two thing team agrees with that necessarily that at least danny when i was talking to him and discord seemed to think that he believes that it will be possible to keep the two pretty separate uh where each one lives entirely encapsulated like in a sandbox inside effectively yes that's that's that on a technical level yes on a on a specifications level i've from talking to danny before it seems like there needs to be a merging of basically the eip repo will be used for each two specs at some point i see yeah i don't know that i don't know how to handle that yet okay you don't have to know today i just want

to kind of put it on your radar no and that that is something uh we'll have to sit down with danny and the e2 team and figure out i see them as as it is just right um i see it as working out i guess but i don't see how it works out yet and i know greg has publicly been a little bit um on the fence it seems like or against um some of the merging this early in the game which i can understand and somewhat agree with but um because it might need to happen it just depends does it happen once it's actually implemented and on chain or does it happen after right before then it's kind of a timing issue more or less i think

if if eth2 becomes aetherium like what we all refer to as ethereum i don't think there's a disagreement that it won't be in the eips repo as it is today yeah and uh where the intersection of if it's something that's going on to the eth1 chain and having it go through an eip and e and eth 1.0 specs makes sense so i think the my view stance on this is that eips are a great tool it's a very very useful primitive for specifying things but there exists a size of a specification that is so large that eips no longer makes sense for it

a good corollary for this is rfcs are a great way to specify things for the internet but browser specifications are way too big to put into a bunch of rfcs so they have their own separate specification system for designing browsers that is outside of rfcs and i personally think that is acceptable and very reasonable and in this case i feel like eth2 is very much across the line of it is way too big to put into an eip like trying to specify all of these two in one or more eips sounds like an insane task to me and i would not want to be on the team that's to do that and so i feel like for eventually when we do want you know either one needs to to combine in some

way i think it's perfectly reasonable in my opinion to say you know eaps are a great tool but it's a tool that doesn't make sense in this case and so it's okay for the eth1 1.0 specs repo to point at the e2 specs repo instead of pointing an eip like it normally would yep i also like that i i like that with the caveat that after eth2 launches i'm on my current position without thinking about it for more than a couple days is that once eth2 launches phase zero any changes to phase zero tweaks or anything that would be eip sized can go in the eip's repo sort of like how we have the yellow paper that

launched ethereum and the eip was used a repo was used later i yeah i would agree with that too because eath phase zero is still uh eth2 phase zero is still on each one yes it is well okay that's yes and no the beacon chain is not on either one yeah so there i mean there are things that are outside but stuff that needs to go into the eth1 chain could either you could go from an eip to the eth1 specs or you could go from an eip to having it be the change to the beacon chain that would be yes an erc technically but you you're right to say it's an eip

because an erc is an eip so it'd be fine that that's also be fine either way and and i don't think that uh and that uh that works well with what micah was saying is there still is this big umbrella of eth2 that doesn't need to be specified but if you're changing the beacon chain or if you're changing the deposit contract on each one then going through an eip to make that change makes sense anybody else have opinions or things on this does that fit is that fitting mica with what you're saying yeah totally it's just for that initial i think the yellow paper example is another great example where we had we did not do eips for every single change from nothing like

technically we started at zero right and then we iterated to a yellow paper but we didn't do like a million little eips we just had a single yellow paper so yes that works for me perfectly and i predict danny will be fine with that from my conversations with him just like one-on-one about this from the past few months when he's been like hey what's the cip rule and i kind of like walk them through it and stuff um so i think he'll be fine with that um and we have one more minute left was there anything that anyone wanted to get to in the last minute that we um that would be like a stopper for them pursuing something in the next uh two weeks uh have we got the eip triaging

permissions the ad for like plan that should have been that should have been taken off because it turns out we can't unless we update the oh you know what i did say i was going to ask the devops team but um i and i didn't yet but i'm like pretty like 80 sure they're going to say it's cost prohibitive to do that and the reason for that is the to change the type of github purchasing structure or like what's it called to change the type of organization structure from every private repo you pay for to every user you pay for would be much more expensive because we have so many users in the org yeah okay then it would be kind of good

to think about a different way we could have the the pre-editor permissions i'd be comfortable because really an eip editor is a is a status it's not a technical permission set it is right now but it doesn't have to be so i can make people in the repo have right permissions as long as they know the scope of what they can do and it's slightly monitored so they don't merge anything they just do labels kind of a thing and i mean i think we trust like client to do that i would just be needed to talk about what the other editors kind of a thing yeah i'd like that because i'd i just like to get him in there working yeah if you want if you still want to like client so it's up to you

yeah that sounds good i'm happy to guinea pig that and you see how it works out yeah so that could be a then a precedent for trusted people getting right permissions i'd love for that to happen what do you think michael yeah okay i'll put a note to talk to the other editors on that on that topic i'm going to be partially unavailable for the next two to four weeks and i believe i'm the only person actively approving p and reviewing prs in the ips repo right now so they're going to unless someone else steps up they're going to really start backing up very soon okay um can you message me just a quick i haven't done

that in a while uh if you could just message me like a couple sentences of your process is it pretty much just going through and a new one comes in and you comment on it or only when we're called uh so i i subscribe and github to the eips repo when i see a new pr i review it and if i see someone touch it touch it i go check to see if the touches address whatever feedback i gave if so then i do a review if not i wait for them to finish that's my whole process okay i'll be gone half of next week but otherwise i should be fine with uh doing that so i'm gonna put that down too okay i'm hoping i can score about some time i just i don't expect to yeah don't pressure yourself with it i'll i'll me and greg

will handle it and we can i can ask greg to help some too all right anybody else have anything okay the next meeting is october 7th i thought this was a really good meeting thanks everyone for your comments and especially thanks to puja for the all the diagrams and the and the presentation that was very helpful otherwise we would have been just talking with words and that's not good for this type of thing yes yes thank you talking with words is the worst okay bye everyone have a good day thank you bye everyone