EIPIP Meeting 71

Transcript

good morning everyone welcome to EAP meeting 71 I have shared agenda in chat and we have added a few topics for discussion the first few sub items are issues taken from the EIP GitHub repository maybe we can start from there so the first one is to propose policy last call changes shall be separated from the pr to move to final I guess this was added by Victor but I don't see Victor on the call right now oh it I think this already is policy maybe we just need to write it down somewhere it's just that when you make a big change to an even last call that

should restart the timer all right so um part of this was also suggested by you in the last meeting with the EAP editing office hour I guess the person has to make a new PR to make it to final I mean like a separate PR from the last call changes is my understanding correct it's not necessarily just a separate PR it's just that if you make a large change to an EIP in last call it should restart the last call timer okay yeah so like you have to let it sit for another two weeks kind of thing right so we can just mention this as an

outcome yeah okay cool the next one is a hide stagnant and withdrawn eips from the eipa list uh issue number is 6027 any thoughts from people here um it's a bad idea for some reason animals that was the favorite of it's a bad idea yeah I mean why do we want to hide stagnant and withdrawn we just want to share all the uh proposals or statuses

right yeah it's stagnant especially the author doesn't necessarily have anything to do with that Google doesn't have anything to do with that um so um feel you can just wind up with VIPs that have gone to stagnant they're still out there in Google they're still historically interesting Google says here it is you go to that page and where is it um or else Google just stops indexing it and it disappears from history I I don't think it's too high the actual

Erp itself just just the list but yeah I can see how that would make it harder to to index it um I'd be okay with displaying them separately um I think we might already do that yeah we do so um yeah I I don't think we need to make this change this is a reason I always prefer the ietf policy if everything's the draft and then it has a status but um we already lost that no no point going back

I think there is also a full request Association this particular I am sharing here the link in chat if people would like to review and yeah it looks like the proposer is also in favor of creating a toggle button instead of hiding it all from the our dashboard yeah then it's just a UI issue

yeah yeah okay so is it safe to assume that uh um there's a real point the table of contents push them towards the end you can all right looks like looks like generally not in favor of this uh proposal or to like hide stagnant and withdrawal eips from the EAP list so maybe we can leave a comment over there um

the next sub item is changes to final EIP so I have found a bunch of eids which are already into final statuses and uh authors have requested certain changes sometimes the original author and sometimes any contributor from the community so um I have listed all of them the first one here for references number 6104 I'm sharing here Link in the chat generally speaking we are aware that EIP editors are not very much in favor of having a final proposal getting updated but these are available in the form of pull requests so any comment starts and yeah what to do with the pr would be

nice to have yes I think this one is oh this is an author that approved it this is probably just waiting on me to merge it yes okay so the next one is a change which is recommended for EIP 20 um obviously there are some strong opinion about it but if people from this group may also add their thoughts so eap20 is like a very old EIP which

has been widely accepted so main concern here is to have it uh have these changes added to erp20 all together or maybe have a new proposal instead if it's I haven't actually looked through the EIP the the pr yet but if it's just formatting changes that I'm fine with making them um I think that's okay but uh yeah [Music] I think Matt you had a strong opinion on that maybe if you would like to add why uh you think it is not a good idea to have new recommendation fit in for

these proposal sorry new recommendation for which proposal uh the pull request number is 6038 for updating EIP 20 run away to fit most current eip1 recommendations oh yeah I mean I don't think that we should be updating old eips and erc's foreign with that too I mean occasionally like smaller changes

I guess is okay but I think this is a pretty large change especially like this is a extremely um widely read EIP it would be weird to make large changes to it which PR are we talking about 6038 you can find the link in the chat yeah I found it there were a few other links so I wasn't sure um um

foreign so it is about the usage of license changes uh with the The Proposal which has been recently merged yeah we sure don't want to mess with the RSA 20 more than necessary yes these changes definitely go further than the minimum required to to meet the current standards so like as written I wouldn't approve this um so do we want to have further edits in the

pull request or do we want to have um like not include these changes in eip-21 together uh I think it's fairly nuanced I can make some comments on the actual PR um like I think moving like simple summary to description I think that's a perfectly fine thing to do um but changing it from like solidity 0.4.17 to 0.8.17 I think is way out of line for what we should be doing um what's everybody else's opinion I agree all right it seems most of the editors

are in agreement that we should not go for the bigger changes to eaps which are already into final statuses so uh for this weekend uh like maybe you know drop this pull request we can close this but comment very well uh the next uh slow down this this does bring up an interesting issue because the solidity code is out of date um people use this use people use this to build on and we're giving them a version of solidity that won't compile anymore possibly um but I don't know in general how we

how we want to handle that or just leave it to the user um well I want to compile I don't know yet over time solidity versions are not backwards compatible yeah like sometimes they add the call data memory thing right and old databases don't yeah oh I mean I guess because they've pegged the version there that there's no need to up update it it's like usually a while yeah yeah it's it's you have to tag the version or you don't you don't know what language you're looking at with solidity um

so yeah it's it's generally unfortunate that we use that we use solidity for this sort of specification but um I I just don't know if we should have a way to update these things once they get grotesquely out of date yeah I'm also yeah I agree with that I I don't know what to do yeah I guess it could take a new PR um but that seems silly when nothing changed nothing changed um I guess it's a matter of just if the solidity gets to where it just

won't compile without you know really obvious changes you know and I don't I don't know solidity well enough to judge um if this is still if this is still going to compile okay okay is it safe to summarize that the current PR in the current form may not be able to merge like editors do not have consensus on them on that however if we are changing the solidity version it may require a new pull request to um change or maybe a new pull request

can be sent out for further consideration yeah it's just a dangerous thing um making sure that the new salinity really does specify the same thing as the old solidity when things are not backwards compatible and there is no formal specification for solidity so um so and the alternative argument is just leave it be because that you can figure out from that what the author's intent was um foreign

so uh with this meeting we can I mean I'm trying to summarize it and I will add the summary to this agenda only for whatever we have discussed obviously that will be also noted in the notes uh but for this particular pull request uh we do not get uh General consensus here however we are considering updating solidity for older proposals not specific to eap20 but in general um I'm not saying we should I'm just saying there is an issue here to keep in mind um that I don't it there's no way we can go back through all of the APS and update their solidity but it is an issue and uh especially if

the authors of an EIP feel a need but it it doesn't seem right to alter a final EIP um I'm just pointing out there's an issue and uh it may take a new IP to do it we may in the future want to to separate that out um this is a fairly unusual EIP I think in that way but right maybe we can create an issue on EIP GitHub to discuss about updating solidity in earlier proposals um okay thank you Sam yeah I don't I don't know if the author of this one wants to

sort of take take that on as as trimming this one back somehow keeping a discussion going um or or of having this one directed uh uh it's it's our Panda here anyway is he on the call you know yeah so we should kick this down the road until she's he's here to talk about it very well we are already creating I mean Sam is already creating an issue for further discussion for updating solidity concern moving on to the next pull request which

is there for updating eip721 which is again in final status a pull request number is 6012 any thoughts and comments on that PR oud this pull request is by the original author uh it looks like yeah there are some people are in favor and some are not yeah if we don't have any thought right

away I am also trying to just share these PRS here so editors may take a look even after the call and the last one here is um we'll request number sorry yeah please go ahead great I'm just still trying to figure out this is another final one that we don't want to touch I'm still trying to figure out why he really wants to touch it all right yeah there's a broken link that's basically what what it comes down to

there's a lot of changes here for a broken leg we're looking at 60 12 or yeah yeah just turn off if you hit the three dots on the top right you can turn off the annotations it's just the the bot complaining because it's a really old VIP that cleans it up thank you no problem the only change is is uh the link down at the bottom foreign [Music] is this a normative link

and let's see it is a link to another project that implements save vrc20 it doesn't look like it's part of the spec I don't care I'd rather just remove the link I think that would be it's it's final I don't want to touch it okay it's it's not normative it's not required to understand it if somebody's really motivated they can find it they can find it um and this is why we want to severely limit um outside lengths yeah if Greg is saying to not apply a PR

I'm I'm I think I'm empowered to just close this PR I think we're good well no I mean we've been around and around an outside way this is an example of where they go wrong but it's also an example of where it's not normative so it's not really a problem um it would be much better um it doesn't look like there's much of anything except a link to get to this anyway but I don't uh um I mean it just looks like yeah it's just a it's a link to some code master that's no good the master keeps changing it it should be linked to

a particular uh commit uh here we still hasn't fixed that anyway oh no he finally has a blob to a particular commit yeah I see what he's trying to do he's trying to fix an old mistake yeah okay this is slightly more on the edge um this is 7 21. I mean we've got a whole industry built on this um okay I'm sorry I didn't review this sooner but let me uh

let me go look at that where is that referenced in the text we have a concept of a rata but we we have no process for it yeah um so it it's long past time perhaps to just get our act together on a rata and then we can and we can handle these things um

yeah because this is an old one and it's dense with references um yeah this this is harder than I think because it's all right now we don't have to like decide on it right away I just wanted to bring it to attention so a writers may leave their comment and feedback if it is missed by any chance and if we can quickly come up on decision for anything listed here that would be really nice to have

yeah okay this is also an example of why outside links are useful in motivations and rationales because he's basically going through existing and prior art in the rationale and it's in standards who are generally a good idea to take account of prior art when you're standardizing something so without the links he's just going to be making bald assertions about prior art with no Links at all um so I'm really inclined to take this as an opportunity to define a process for

rata and then these can be handled as errors um without without actually modifying the the final text I mean I'm I'm down to you know have some thoughts about Errata and what you know what we're allowed to change and yeah so I'm just I'm seeing here I mean it's old so things aren't broken out everybody's got you know some standards he's referencing I think some of that's actually normative some issues various discussions um and the others clearly not normative

but a lot of it prior art that he's trying to um trying to incorporate um either directly um um yeah I mean like these he's referring ERC 165 that kind of looks to be normative um yeah I'm really inclined to throw it back to the authors once we've got on a router process and fix this one up somehow because it's it's a very important Erp

it it's important that people can understand it um and okay it's worth trying to sort out those links that really are going to cause a problem understanding it in which ones which ones can rot without it being an issue um as at least as I've discussed it what's what's in the specification has to be normative and what's not in the specification is not normative yeah and this this CIP they're they're

mixed together I'm tempted for this one just to say that it doesn't hurt the understandability of the EIP to let this link rot um so we just leave it but we mentioned that you know we we might have a more formal Errata process and we can revisit the issue at that time okay you're all right with that Matt that sounds good to me yeah I I would kick back to William that there is an issue here but it's worth you know try to sort out which of these links are normative and which aren't

yeah um because the ones that are normative um we need to keep an eye on um yep I think maybe we can have a an issue for one of the upcoming meetings for the process of erata and we can have more discussion on how to define the process and for this for this PR um if you can maybe leave feedback that to distinguish between normative and non-normative links that would be nice if Williams or the author responds to that very well otherwise we can let it

be there for some more time for yeah makes sense all right uh with that maybe we can move on to the item number two oh sorry a before item number two there is one last or final EIP related discussion needed which is for pull request number 5877 so this is for another final eip155 this is again a very old proposal

um authored by vitalik for simple replay attack protection so the proposal is willing to add additional line for ganache GUI private chains okay there's a comment in the chat that

one should not go in okay so is this um this is a list of the existing chains at the time right yeah yes clearly may not be there anymore right yeah so yeah we we aren't going to do this there's no way we're modifying e155 um it probably shouldn't have had a list in it in the first place um and eips are not the best place to maintain lists so I'm I'm just gonna close this unless somebody objects any objection from present group of EAP

editors for closing the pr I should be more clear yeah all right it does not look like people are opposing anyway we have heard consensus from editors that generally they are not in favor of modifying the existing eips and as you mentioned this is not a good place to maintain table so yeah we can probably go ahead and close this one moving on to item number two uh this is part of continued from earlier meeting discussions because we have

discussed this in the past however there is a new proposal on the table it's a straw man proposal proposed by Victor um I suppose Victor is here if you would like to maybe summarize your proposal and yeah people can share their thoughts and opinion yeah so uh the idea is that I heard uh from various authors and editors that there's no clear um nuclear criterias for advancing status some would like a very easy way to go go through um to get to final something going to go into I know is too fast something uh going to find out didn't have some of the IP didn't have enough consensus or

demonstrated interest to go to final so this is an attempt to to formalize what it means as a criteria for each status and the Highlight is that for what we already know uh core of obviously required client implementations and imply I mean I understand the implant in implied uh level of um what it means to uh client implementation is multiple client implementation and getting adopted in the hard Fork but uh when it comes to erc's network and interfaces there's no higher requirements and and in the discussions on raised concerns that if

some VIPs go into final too fast we also saw uh things like uh EIP 7.17 12. and that was like going into final status um prematurely it has a lot of interest it's being widely adopted but it's editorially a disaster we all I've seen that uh I also recently discovered things like tweet four seven five which has had a lot of editorial issues even after the it passes does the final so just want to kind of propose something that people can agree on um one of the contentious um

uh ideas to attack I think is whether we want to require also implementations for network interface and ERC uh just as if we are we require for the core um I am personally in favor of that because I think a standard without multiple implementations is now counted as a standard because and it doesn't make sense to finalize them if no one really cares or care enough to implement and deploy it um the other thing that people propose I heard is that lower bound which I think poja here is in favor like some of uh recently another authors in

the same thread proposed a upper Bell which is deadline to move to the next step um so I just want to put it on the table for the uh bring it up to the attention to this group and see what you generally are um the current proposal is that for all the standard track uh it's based on um enough discussion and implementations to advance to final and for MATA and informal it would be more editorial agreements and consensus and wait even longer so yeah I would just pause here to see what you think I I don't want to add any more requirements that make it more difficult

to get an EIP um finalized and I think we make it very clear that final is not an indicator of adoption or or um or or use or quality of the eips like technical merits it's just a statement about like if it's going to change or not um and I think adding like multiple requirements for like implementations or or having certain levels of adoption before we move to final I think that's that's going to be too taxing on the EIP process and I think like what benefit is it going to bring us it's going to bring us that most standards like even more standards don't make it through the

process and just sit in draft or in review for longer periods of time I don't think it's going to help anything um and on the like minimum length of time but between changing statuses I think that's I don't know it just seems like adding delays for no reason maybe we need to do a better job as editors uh of making sure that sufficient discussion has has taken place but I don't think a Time bound is going to change anything like Eep 712 was sitting in stagnant for years and it still ended up a mess like I I I don't think a time limit is going to improve anything if more people

aren't looking at it I heard the same says um didn't want to text authors more or completing either a barrier to advance the final uh so that we don't have a lot of VIP laying at I'd like draft Tour review status um yeah what do dragon uh and Matt think I mostly Echo what Sam said I'd really think that

we spent a lot of time trying to separate the concept of like Readiness for from eips and just have it you know moving something to a place that's fixed and then letting like the Readiness be defined outside the process so I think this is a regression in that sense yeah uh how about Greg I think Greg just Oh no you're just have pooja's icon again and that's funny again um yeah yeah I don't have a really strong opinion on this except yeah not too many more obstacles

yeah my intention is not just to react uh my intention is not thought to kind of propose something to add object obstacles but every once in a while I heard uh for example editors or other authors comes in and says why is this even the CIP even worthy that's one thing and then that creates a lot of debate if we can say uh the worthiness is is not going to be control unilaterally by either the author or by the um by by the editors that would be a good thing because uh I on one side I worry that if we disallowed authors to uh to uh to propose VIPs and then they'll be like unless you guys are all

super open which I can also turn into uh but then we would be anticipating like 10 000 left other Humanity 10 000 of VIPs are coming in and I doubted to uh if that is what this repository wants and the other thing is that uh either we let editors single-handedly or as a group decide whether an EIP is at worth it it's also kind of placing a lot of Burden as well as a lot of single uh subjective bias um to pip editors some may argue that how about we look at the thread and see who is on the discussion and that's still very subjective and therefore um the worthiness we were looking trying

to look for something that is more objective in determining worldiness Readiness is the same we've seen interfaces that we're not even compatible in Readiness and then it's still made into final and so that's why we want to like propose some of the implementation uh requirements to at least make sure that it works do we ever determine worthiness some I think implied like uh one of the eips that uh I was I interact with being asked by an editor like is it useful or is it Worthy and that made if that is a technical peer and feedback that's fine but as an

editor asking that might imply that there's a gap editorially to enter an EIP yeah so I think you know asking if an EIP is worthy or not is fine um but if the author says yes then I don't think any of us will stop it from going through the only time I think we would stop it is for eips that are not expected to have multiple implementations that have to like uh interrupt that that is I think the only bar for worthiness that we enforce that's true that's right but that's pretty subjective right like how do you know if there is going to be we're going to not be uh implemented

rotations it's not whether there will be or won't be it's whether this stand like whether the um The Proposal um standardizes something that would have multiple implementations like even if there's only ever one implementation of it and it's by the EIP author that's fine if you standardize it it's it's whether or not like there's the expectation that uh somebody else could come along and make another compatible implementation well for me it's I'm okay to reduce that down to one implementation um I'm more in favor of having multiple one but I'm I'm okay I think it's okay

to require at least one but uh We've also seen eips go in without like showing or without having implementations and finalized and that's what I felt the last the gap um I think one one thing could happen is that EIP did not work like that that specification did not work and waste editors were future authors time to look into like waste um not author but why implementator implementers time to look into right a final EIP that doesn't work yeah I mean that is kind of annoying and

I mean that's kind of what the discussion threads are for like if if an EIP doesn't work somebody on there probably would have said something and hopefully kind of finally IPP withdrawn is that allowed how does that work yeah that's that's why I'm trying to like I I I I do hear the sentiment in this in this room today um that um you you don't want to add hurdles to um uh altars I I'm fully in uh in that I I love to have authors be more easier to make it easier for them to propose and then work through and I consider myself mostly an author but um uh I just want to like put it here

and then see maybe six months from now this will come back up and then we can still we can continue to use that as a basis to discuss what kind of criteria we want to require for our advancing at status any anytime anyone is a complain about why something goes into final too fast or too slow maybe we can use that thread as a discussion how can we better improve our process to set an expectation um and and and and standards for something to be expected for the status advancing to be expected foreign I am not sure of any EIP so far which

has been into final status and it was like not working so the idea of standardizing is to have a standardized process in place like the codes in place for which uh any implementer any adapt developer May pick up that standard and try to add it to the project if they won't want to integrate that concept into that project and adding too much boundaries for people to even submit a proposal to become a standard is something I think is not very fair to them however I am open to the idea like when we have this kind of examples we

can probably come up with some other policies just like Sam mentioned that if we can have finally ipv withdrawn so if we found like if we come across a proposal which is actually not functional which I think is not going to happen because multiple eyes are there on any proposal the moment it enter into a pull request or goes to a fellowship of ethereum magician so that's rare of rarest case that a proposal could get into the final status and for that we should not increase our boundaries however I am into favor of like kind of defining um not defining or maybe setting hard line over there but a general idea of getting more discussion into discussion thread uh if I have not mistaken uh this

proposal idea may have been fired by a pull request that I found for a meta Eep which is currently into last call and it would be uh finishing its last call under 30 days which I really think is not a good idea for proposals under Mata category because that is process related proposal should be discussed in eipip meeting so we can think of something around like how we can increase the length of discussion but not hard coding that length of discussion onto the EIP one is my card yeah we have started the uh the peer review

process where we nominate people from the list so I think that'll help a little bit you know not for meta eips obviously but for regular ones right my type is mostly related to process so I think EAP editors must look into it and any meta should not get into a final status in less than a month or so so yeah I'm even in favor setting it as a 60 days for meta because if something is procedural uh it should take longer for the it should let more authors know and authors don't like editors that who look at the EIP repository and

discussion so frequently um it just comes to my mind that the period of 14 days definitely gave us one eipip meeting in between uh last call to final status um I mean obviously I can bring it up in the meeting but yeah any other thoughts on there yeah

I I agree that uh some arbitrary period of time doesn't necessarily help there's a bigger issue there's a bigger issue with these as to whether we really should have an implementation before it goes final uh with core eips by the time it goes final it's on the main net um and a uh many RC is a lot more useful if if there isn't an implementation and people know it works yeah for ANSI standards work we wouldn't we would not uh we would not accept uh Library proposals which were

our non-core proposals that we would not accept them without it well I shouldn't say not our strong desire was to have an implementation to standardize what was already implemented so it would seem reasonable to to generally not go to last call or at least not come out of it with without an implementation um that would be an indicator as to whether there was enough interest to proceed if if nobody wants to implement it what's the point yeah that yeah I that's what I felt too and by the way this is not just to to to

to kind of add hurdle for something to be proposed this is just adding some bar for something to finalize and um just to make one to make the distinct Extinction clear so my general understanding of timeline here is from a proposal when it is added to a GitHub repository till the time it reaches last call generally they take up three to four weeks in normal cases like sometimes there are a lot of proposals it takes time to review all these proposals and all and on top of that if

we add 60 days for final call I mean like last call that would defining the length of any meta or informational EIP cannot be less than three months and uh sometimes if the initial period is over a month say for example it is two or three months already then adding additional two months will be like maybe author may lose interest in pursuing the proposal and that will stagnant and even if it is a good proposal author may lose interest so generally speaking not in favor of setting a hard set boundary over there of 60 days however

um yeah I think the process that was discussed in the last meeting of peer reviewer and adding more reviewer would be good idea for having implementation core eips follow a little different process so we can just exclude that because that is to be implemented by the client team for ERC I think we discussed in the last meeting as well that having maybe a prototype of that would be also a good idea or yeah having a strong discussion on that would be a good idea but waiting till the implementation is ready because the proposal may not have time and bandwidth to implement it he or she may have to find someone else

to get it implemented on a project level um I agree to most of the points um in the matter of waiting for 60 days you mentioned that the author may lose their interest in pursuing um I think if you're proposing a matter which is a fact not not to say those old matter that's only recording the hard work but then in in the in the late latest status we use mostly use beta for a procedure right if someone propose a meta EIP and lose interest in the future after just 50

days um I don't think that is strong enough interest for on the other hand if something is really important and agreed has a lot of consensus by this group even if the author loses interest the matter in AIP can still advance to final right if they get into the last call sufficiently because the group will also continue to take on and just finalize it just like we see for other standard eips I wouldn't feel too uncomfortable for we to require a longer waiting period of

time for people to give feedback for MATA for information I really don't care because it's non-bonding I even think oh information or should only be live and and okay to have subject to Future change but yeah that's that's my opinion well we are very close to time so if anyone would like to and give final piece of thought and feedback here we do not have any pull requests so we do not have to make any decision however we do have a discussion thread of at Fellowship of ethereum

magician and Link can be found in agenda so people can definitely add their thoughts there but yeah if anyone would like to give any panel piece of feedback okay so I think we can continue collecting more feedbacks and we'll try to revisit this discussion in future meeting um for today's meeting I also wanted to bring another issue for discussion I know we don't have time to finish up the discussion but at least we can collect

initial feedback on that so okay that is related to EIP bot I'm skipping one item I'm going to item number three directly request section that we discussed briefly in the EIP editing office hour so uh for for required section at present the eapw bot allows final stagnant and withdrawn EIP my proposal here is that withdrawn EIP may be removed from there because a withdrawn EIP may not have a necessarily followed throughout the steps of a standardization and may not be ready to

be um uh to be an EIP which which can be considered for dependency I have created an issue for that uh issue number is 6131 if anyone has any thoughts comments to add so I I guess the rule would be withdrawn eips are allowed to have withdrawn eips and that requires a preamble header but no other eips are um is everybody okay with that yeah I think that is a better wording of it yeah thank you Sam for correcting it uh Greg and Victor if you have any

objection on that or maybe on thought sorry I was I was taking notes on the previous discussion yeah I'll take a look you can proceed to next item I think the last one yeah I think yeah anyway we are out of time so um I have added the issue number it is 6131 maybe we can wait for um more thoughts there if nobody objects then hopefully we can make this change is that I think it's very it's it's very well it's very good I'm in full support of it should we also avoid the stagnant

being referenced as required um my concern here is that one author can pull in another EIP as a requirement at a stage like if they're both in draft say which is not a problem and then uh the one that they're referring to requiring uh falls into stagnant or gets withdrawn and then what does the original author have to do

one correction I would like to mention here like by mistake I said uh the current eipw allows for final withdrawn and stagnant actually it is final living and withdrawn stagnant is not considered in the first place so uh the only status which is under question is withdrawn should it allow withdrawn in the required section or should not well probably not um but maybe this is an old worry but it is a pain if if you referred to another draft and the draft slips off to stagnant uh should you have to go take over what went stagnant and make it a draft again

in order for your proposal to proceed um foreign it is not allowing drug at all only final and living proposals I I I'm in favor of letting draft and review status as we as flexible as possible and reference anything like even if it's a stagnant work or or I'm okay to ban or not ban which one but I think if we give a draft and review bigger flexibility that's okay I think for last call uh to getting into last call they want to make sure that uh the required the required EIP the depending the depend

EIP being depend on should also be in at least last call um because something go into last call is soon to finalize and should be treated more uh seriously and if at that point something still either stagnant or withdrawn the author should feel enough either remove them or remove the requires if it's not a high dependency or be motivated enough to pull and take over and then drive that into uh into uh last call if the depending required EIP is a is a requirement

I think that would be too much of hassle for editors if they start allowing draft and review because as Greg was mentioning that there are chances that they may end up on withdrawn or stagnant so to be on the safer side I think it's a good idea for bot to allow only final and living and yeah even withdrawn can be taken out except for uh the withdrawn proposal well I think what I said is um you for Bots to not even complain for Drafting and reviews like for if if this EIP is in draft status or yeah S4 reviews so just don't complain about requirements

requires so review I think we have to have the Restriction because like if it's in the requires header it's required reading like it's necessary to understand the current EIP so if the current EIP is be is ready for review that means all of its dependencies also need to be ready for review like you can't review an EIP uh the one you're looking at right now if it's dependencies are still allowed to change freely like it they have to move in in somewhat of a lock step here like uh for draft it's fine like draft can refer to draft obviously but and yeah so yeah I don't have a problem with draft

referring to to Something in any state um yeah exactly so draft and stagnant can refer to anything um and yeah that just means if you want to move out of draft into review yeah you'll have to somehow resurrect um what what slipped out of what slipped out of draft but okay I think I think I understand cool so I have to drop off sorry guys but uh thanks for coming out I'll talk to you soon yeah I I think thank you everyone um I'm not sure when the next meeting will be because it is falling on vacation time so maybe I can take a poll or ask

people on the grip and see if we would like to keep the next meeting on 28th or in January well thank you everyone for joining have a good one thank you