EIPIP Meeting 82

Transcript

welcome to EIP IP meeting 82 and I have shared agenda in chat it is issue number 235 on eipip repo we have added the item to be discussed from open issues and pull requests from the EIP GitHub repository and we will also take a look at monthly stats for different reports that we publish starting with the first item listed here which is uh discussed open issues um I think the first one with respect to patent has already been merged before this meeting so we're gonna mark them as chat the next big item for discussion was proposed by Matt

I don't see him here um the item was issue with auto review bot I don't know if anyone else here has any update or anything to share on that particular topic if not maybe we can get back to this topic when Matt joins the call uh if today if not then we'll bring it in the next meeting moving on to the next item listed here which is issues with cl link validation and this issue is created by Tim Bako and we briefly discussed this also in

the EIP iting office hour yesterday if you would like to maybe briefly talk about the potential roadblocker here and what we would like to get agreement on today yeah so the issues that basically when PR people draft PRS they mentioned to request and since real live links in consensus specs and execution specs so the expectation is that PR studies weapons should be allowed at least in the draft and because

in the draft there is basically cover uh quite a number of files number of files as well as uh you know those yesterday we also discussed that if there was a possibility of uh putting the commit link of the PR but even that there is an issue that committing generally if you got from GitHub it belongs to their service repository so uh which this even will not be concerned suspects or execution specs

and again you know commit can be uh print out or run the management in the main Depot even then uh the commits uh I will commit would be created a special effects ration uh expression match so basically the idea is to allow request for drafts here and uh then basically you know uh if on the review then there has to be a static blog uh that points to those repos [Music]

foreign [Music] sorry Okay so

um so it looks like um there is a one Comet related like a we can have a specific comment added to the EIP documentation does anyone disagree with that like can we have it or do we want to go ahead with to do thing Victor I see you unmute oh yeah please go ahead uh Sam oh uh my concern with allowing links in draft and then uh forcing people to remove them if they go to review um it's kind of two things so uh things stick and draft for a lot longer than

they're supposed to so um that's a common problem um and the other one is that it might hold proposals from going to review when they would otherwise be ready to do so if the pull request hasn't been merged yet um but I think there's a relatively minor concerns um I I do worry that adding these like relaxations for draft um proposals will be will lead to more of the similar things but you know we can cross that bridge when we get to it I'm generally in favor of allowing this uh allow pull request in the draft status

yep same here in favor of following three hours and drafts sorry I don't think I'm following what do you mean by allow PRS in draft so basically allow referring to your circumstances specs and execution specs in uh in the draft erps uh so once they have to move to review then we require them to have permalinks rather than PR links and what is this what when are we saying

this is a problem the current link but this allowed that and it's also not included in the 55757 The Proposal is to allow it and we probably need to add it to 5757 I mean I understand that's the proposal I just don't understand when do we want to refer to a pull request so there is a PR by the outline which basically refers to a PR and Tim also has created an issue where he basically runs that one can refer to pairs photography IPS it's the issue number 7064

yeah I mean yeah I see it I just don't understand why they don't merge this to consensus specs like is there some sort of ordering problem I think so I mean uh to that particular proposal that imagine two content suspects is like going it taking it to final status and I mean uh basically putting in draft accepting drafting it means that you know uh it it is to be discussed and among the viewers and all that right so basically merging to consensus specs and accepting in

draft in my opinion are two different things I mean this thing from tapline is two lines like he doesn't have the spec there so honestly I don't really see like yeah I don't really understand why he doesn't write this back in EIP sorry so basically that's better respect so I mean a person would mention that if batch in the EIP

yeah I just I don't I don't really feel like we should be adding diffs to eips like this it feels sort of weird and that's the point that okay for drugs at least we can allow it and obviously post draft uh for the review status it has to be a proper uh blah blink prospects or a directory everywhere so so the point is to relax for draft so that it can easily help in discussion and all that I think that makes sense

yeah I don't think that we should be allowing links to pull requests frankly yeah I'm of the same mind I I am in favor of allowing all requests links to pull requests it's more a process smell like if we're allowing links for pull requests that means that there's something wrong with The Ordering of the process or the way that we think about the process there's a lot of distortion for me but we're talking about a link to consensus specs right it's a link to a pull request to the consensus specs

um and why can't it link into the the most recent spec itself they haven't merged the change to the consensus speculate so there's not anything in the repo there's no commit that they can link to and this and this is a draft we're talking about we're talking about allowing this for draft eips so he really has no choice but either to link to the commit or in English describe what it is the commit is which provides a lot less information to the reviewers

yeah I mean I don't think that the way that we have it right now is very good because then if you want to make an EIP to describe a CL change you have to wait until you merge it to the CL that's not really ideal I agree but I don't think that allowing links to PRS is the right approach PR's to the consent suspect are quite different because it's the only spec we've got I would still suggest that we just link to the most recent commit of the pr like I don't think that works but the most recent belong to the source it was great so GitHub does add those commits to the

destination repository so you can link to them from there are you sure uh yeah I just added a comment to the issue [Music] so I I think I I don't know why you are objecting to that uh I think if you um maybe you help me understand it better if the goal is to disallow link uh because the link can be disappearing then linking to a commit it can also disappear if it's not fully merged right if not it's not merged in the master basically I mean even if it is merged it could be yeah yeah there's there's definitely like like I said in the comment I think there's a whole other

class of problems we need to think about there like at least if you have the commit hash you can verify that what you have is what's linked to in the commit or in the EIP but um yeah the availability is is definitely a concern there yeah but uh you can't guarantee that anyway and then we're talking about draft right I don't know how much special privilege we want to give draft eips we're just making it very hard I think um so if we understand it correctly salmon matches uh disagreeing and then uh their gender and Gavin and I are agreeing

we should we put that in her own hold with and revisit under certain circumstances or do we call that a um a consensus already do we have any blocking objection I mean I really want to allow it because there's really no other way to refer to the consensus back and I think if it's committed it's not going to go away we do allow linking to the consensus spec as long as it's committed yeah so what are they supposed to do so I'm suggesting they link to the most recent commit of the pull request as the link

except that it that's not right what do you mean he's then he's not linking to something which is in fact what he needs to link to the alternative is tell them you can't you can't put the draft in until the consensus spec um corresponds to what the draft is depending on so yeah maybe you can explain why linking to the most recent commit isn't linking to the thing that they need to link to because they might have not yet accept that in consensus they want to like propose it and have people discuss with

it that's why they don't get though yeah accepted yet accepted and merged that that's the whole purpose of proposal right yeah but so if you link to a pull request and somebody reads the EIP at that pull request like like they read that EIP today and then the portal request completely changes purpose and does something else um then what you reviewed when you read the EIP isn't what is getting like implemented they don't match up I think we we can allow for campaign lengths so that you know uh that this does not really change

uh so so we uh so it seems like uh that content suspect will have that commit as Sam already mentioned in the comment so now what what we are a person can do so you can basically generate a company's link that will do and this would a source coming down the target commit and that will not that will that is that that is a static one so that should both it should just give the diff we have a general problem here then that um

if we have an execution layer proposal or if we have a consensus layer proposal that depends on the other layer the proposals you know pretty much have to go in together but you know to say that we can't actually link from one to the other until there's a full PR ready to go makes it difficult you know pretty much they can't both go to they can't both go to final until it's together and so but both of them are actually in a sort of limbo um so I I just don't see a choice in draft stage and I think think it's more

useful to be able to point to that commit um and yes during the draft stage if that commit is no longer relevant if the consensus group says no there's no consensus on this well then the execution layer spec has a problem but it'll just have to be worked out through the draft stage and through the review stage and through the last call stage and all the way to the final stage before we actually know that that a given proposal is compatible with with the others with the other layer right it's a problem we've created by or that

we have to put up with by having two different layers that are independently specified um you hear me I don't need to repeat that yeah like like to be completely clear I think I am 100 in support of linking to the consensus specs I think we need to have links to consensus specs um just I don't like linking to PRS as an alternative here I'm just wondering like uh if we allow this thing like even if the pr is not merged

um be there in the draft form but we can design the bot if we can update the bot in a way that when the proposal is moved from draft to review make sure that pull request has merged so we do not end up and like you know reviewing the proposal all over again when we when it reaches to last call or final and generally speaking when it is a core proposal that is there for last call when it gets into test net phase right so if we can update our bot at the time of a status change of review what do people think about that yes I think that's what the proposal is

asking for is that we allow PR links in draft but not in other statuses so maybe we can think of like um do we have like enough support for that or do we have someone strongly opposing to that I think that that's generally okay um for you have having a path if I understand you correctly you're suggesting that if there's a bar that can help safeguard that that would be good um I'm in favor of that too um I just think that that shouldn't be a blocking me

um requirement before this get implemented in the process see a comment and no more Bots but I would like to understand um is it possible with eipw yeah yeah I mean aw you can do whatever you wanted to so if you wanted to allow links to poor questions draft and then not in review you can totally do that so so and just so basically why why can't we just you

know a lot of these kind of links where this you know basically I have no problem with allowing links like that Yeah so basically this will solve the problem of showing that if okay so in that case I'm assuming that the bot will be checking for that diff commit instead of the pr like we are still in a position to stop that unless

that is merged in the final spec of consensus is there now at the bot is already checking for uh we we can just expand the regex that was um yeah what which one is the diff link does it has the commits yeah it has like the semester uh two or three dots and I don't ever remember which and then the commit right I mean it it doesn't even need to be monster it can be fixed even a master commit

Ash so we can sort of make sure that yeah that would work um yeah I'm okay allowing links like that I'm okay allowing links to just the tip of the pull request those are both fine as long as it has a commit hash to the URL I'm perfectly fine with it that sounds like uh consensus right so as a summary we can state that uh links Tuple requests are allowed under 12 circumstances when it is tip of the commit

and when it includes a diff and commit hash together but again uh just for authors to be aware of that there could be a bot check when status is changed from draft to review is that the correct summary some and anybody else um yeah I think we still wouldn't allow links to a pull request but that's a technicality it would just be you'd link to the commits in the pull request but yeah sounds good I'm a little worried that there's like a GitHub feature rather than the branch actually being part of the Repository

yes it is that like it is a problem but it's a separate problem um whether we we solve but by having a backup of the the um those repositories with those commits specifically or something else but like um at least right now it is possible to write a verifiable backup of the each repository if we want um it seems we can't really solve these problems until we solve the issue of how to reconcile the consensus specs and the execution specs if we pull the consensus

specs into the EIP process it gets a lot easier okay hopefully we'll get there too very soon um right now um we do not have exact process for consensus packs moving with the EIP process but yeah yes um if anyone could maybe write the response or the summary for this particular action item in the issue so that issue can be closed or if all

quarter would like to discuss it in code of meetings they get to know what is the consensus here with respect to this particular issue it's just sorry just briefly on that if if they're reconciled then there will be an EIP for the consensus change and it just becomes linking from one one EIP to the other and they need to move together um I think that that solves all the problems that we haven't we haven't come to any consensus on whether and how to to pull the processes together

I I think the um consensus outside of the EIP editors is to not pull the processes together any more than they already are well this is one of the problems that one of the problems created by trying to by trying to treat him as completely separate um I I don't like that but so it goes maybe that's an issue for another time um when we get like a strong support in that and we have a proposal we can bring

it in the eipa meeting anyone would like to add anything else before we move on to the next item so I'm taking that uh nursing will be responding to that issue that so that the issue can be closed and will also write a comment to the respective pull request with the eibs all right uh so that's all about it moving on to the earlier item that we missed when lightline was not here so just want to briefly check uh on that is the issue with auto review bot um where are we with that um and we have a

solution or do we get to know why that was not working I have no updates since I turned it off so I I don't know where we are with that is about the auto review bot uh not the number one so did you say but okay oh they are the same one okay perfect okay so uh the error that we received I mean that was mentioned in the Discord chat was because of this review bot okay yes sir I I don't know much about the

review bot so I can't really uh help there and no matter if you if you have any specific question I know panda is not on the call but he left some comments on the Discord if you have any specific question maybe we can communicate when he listens to this meeting later on and I've posted onto this quarter and I've opened some issues and there's still problems with the Bots so yeah I would just like yeah the Bots to a not put lots of errors in your notifications and be to merge whenever you undraft a PR without closing and reopening

yeah that has been an issue for quite some time like I did it has to close and reopen and then only it merges I think it's just a bad look on the reading though okay we can let Panna know about that and hopefully he'll follow the meeting recording later on so he'll be aware of it moving on to the next item here uh that is ERC is a status advancement criteria I suppose this was proposed by uh Victor but before that I just read a comment as I mentioned that he may have to take off in in few minutes um anything specific

Sami would like to discuss no I I see a proposal which is there in final status like the proposal is already in final and there isn't some update for that proposal to be you know um some some specific changes for that proposal and the peer number is 7077 if anyone has any strong opinion on that we can get there too okay okay then let's go sequentially uh coming back to the proposal ERC status advancement criteria uh Victor if you would like to briefly explain what is

the concern here and what are we looking uh from EAP editor script yeah thank you uh poja uh so I have this uh presentation um and and hopefully that if if you're not at your screen that's fine too I'll just verbally also explain so generally we're talking about a proposal for formalize how ERC Advance uh status because currently it's pretty [Music] um subjective to my opinion and then it also reduces the chance that we are capable of of scale scale up our reviewer tech review or editor review appeal so the general goal is to kind of

find what we have in consensus how status advance and then we can so that we can make it better so um and less arbitrary and uh um just want to mention that the the prior art that we have is that core EIP require adoption to finalize and also um VIP and pep both uh that we and that EIP has been inspired by uh requires adoptions to finalize it seems a common practice to require adoptions uh to finalize and also it helped us uh generally

um um kind of testy uh implied requirements whenever we make it allow the ERC to advance which is soundness and usefulness I I I generally personally apply that whenever I am an author I don't apply those requirements when I'm an editor for guarding the status but like as a community member as an author I would assume soundness is new using this is a lot of time what people look for um and so also to mention that it's interesting that I am doing doing some research not only PP is doing requiring reference implementation to be completed uh and to be finaled um and our core EIP

of course uh I uh the rfcs are also doing it um so uh if if if there is any argument I uh that's hey uh erc's uh requests for comments and then they're different from uh the other eips that needs for hard for the Korea a hard work or anything um so um it's interesting that RFC which is what ERC is inspired by also has similar requirements where proposed standard in their case and seems to be strapped in our status that require no reference implementation but uh basically required design choices uh resolved and then also um

desire that desirable instruction argument for the uh for the proposal and the draft in their case which is I see in our case less reviews require at least two independent and interoperable implementations and we need the when it needs to be and it needs a significant implementation and successful operational experience to become a internet standard and so the goal the The Proposal here is that we require at least no requirement for a draft but require one implementation to move to review and I don't know two or three independent implementation to last call and it it's it's I understand that like

how how does it call Implement independent is difficult but like at least have uh two or three implementations for it to be standardized um would be something interesting to me my question um now for the editor and everyone who is on the call is that um how much should we require how much implementation should we require if at all and uh should we use status or should we create something different like I know that internet IFC use maturity so we can either use the status or we can use a different thing so these are the two questions so how much work do you want to do to

verify that a reference implementation is an actual reference implementation um I think to begin with uh we can I I'll be happy to review that and then I'm sure that it can be a very clear um week like it can be a very clear ask if we want to ask the technical peer reviews as long as we have a clear um ask so I wouldn't worry too much about that I I do understand and I agree with you that uh um the the mandates to to review the uh to

to validate that a reference implementation exists is a is over a more overhead work uh for either the editor or technical uh peer reviewers um I I believe that could be solved if we have a clear boundary of what what two uh review yeah I also um any other comments or questions it basically looks pretty good to me

um you know a few details but um I just don't see any huge problem with it I I wouldn't go I wouldn't go for just another variable at this point the status boundaries look about right I don't see a big problem with what counts as an implementation [Music] um if we're pretty much I think that means it runs on the main net uh there should be test cases at some level in the EIP so if it runs on the main net and passes the test cases it's an implementation

I'm taking notes um thank you Greg um you suggest that status just use status without creating a new variable right yeah it shouldn't go to review unless the EIP has test cases and the implementation runs on the main net and passes the test cases okay deployed on main Nets pause cases and just also mention that I think past taste case is a great idea I love that

so I incorporate it in The Proposal one thing that I really like what Sam was doing for wallet is that the proposed a test suit for the compliant wallet and that basically reduces or at least increase the scalability for verifying uh compliance so I really like that um I also yeah I also see that Matt is responding that three seems too high um

so you were saying earlier that um if a reference implementation exists and passes the test cases so does that mean we need to run the test cases against the three reference implementations is that what asses editors are going to be doing I think we might ask the author to demonstrate that would that be okay so we can shift the burden to the burden of proof to the author to say hey uh and then I to my understanding they're more than happy to do that which is hey these are the

um you you probably want to also um verified the implementation and by doing so you can either manually verify them or you can um create test cases so your compliant can run it against them and I think the compliance where the adopters probably want to have some formal test cases as well so that it reduces their overhead of like manually checking whether they comply or not that just a little bit of overhead but I think technically that makes everything scalable and make everyone happier so I I don't want this to sound harsh but

it really just sounds like you're saying we want authors to ask chat gbt to rewrite their reference implementation three times and then that that's it because like there's no I mean obviously this will work for like you know good faith authors but someone who just wants to get their proposal in will just make three different reference implementations upload them on three different GitHub accounts and then that's it their proposal will continue right um I think you're you are if I understand you correctly you are saying that authors can create different reference invitations which aren't uh independent and we are only verifying that they're independent

yeah and it's a Serial basically a civil attack right in some sense yeah exactly um I think here's what I think first of all um you can't even uh like the alternative is don't we don't require it which then we relinquish our ability to even verify ex any reference implementation exists so uh having requirement for reference implementation or adoption is no worse in than current scenario so that's the first thing and the second thing is that we do understand that like in a if we treat it as a security problem

sure it's hard um you can't like completely rule out the chance of civil attack in this case but a lot of authors are reputable and then a lot of people who deploy smart contract have track records on chain which is not too hard to spot a problem um and like completely hiding the the track uh from it is almost is also very hard so I wouldn't um kind of uh think of that as too much of a of blockage for adopting this as a procedure requirement I'm mostly just

wondering like what what is the like goal that you're trying to achieve by requiring additional reference implementations so uh the general motivation is to find a social consensus of what it takes to advance ERC status because alternatively currently I feel it's a little bit too arbitrary and I don't want to tell the Erp authors that hey so long as you don't have links in your erc's and you you comply with all formats and so long as one of the editors in are happy we're allowing you to advance to final what I really want is to make this process less arbitrary where given

um the the scenario of any editors or any good face uh Common Sense editors would be able to make similar judgments so that now that we have seven we can advance to like more people in the future like with similar and approach like we call earlier what we call them technical reviewers um what do we create separate roles for that that's fine uh but like having a subjective more or less subjective uh criteria for advancing them is the goal and can help scale up all the EIP reviews but what problem is the solving

activity yeah the subjectivity so what subjectivity do we have right now because it seems like as long as the person just shows up and moves their EIP to the next status and doesn't break any of the very basic rules they can move their ERC to final and we don't have that many erc's even going to final right now my if I started to uh like allow the very basic uh rule rule of current leaders basically no requirement for ERC to advance right um so so that that is completely unsubjective as well right which is I think which is making ERC less useful it doesn't check for soundness it checks

it doesn't check for usefulness um so that's that's that's what I I want to um propose to make ercb like you've spent so much time discussing how to disallow uh links um I think they're more important uh things to make ERC really works and they're really useful and then we do seem every once in a while the question comes up hey is this ERC useful at all or should we reject them or not um but given the standard if we are approaching approaches so long as a authors show up and Advance their ER status then that question should not come up

I presume there's some implied social consensus that we require soundness we require usefulness but I don't know if that is your consensus like can I throw meaningless thing on ERC draft so the only two things the only two things that I review for are um does it meet a minimum bar of like you different parties need to communicate with each other so that's kind of like the the absolute minimum bar for making a standard is are there going to be multiple implementers or multiple consumers of it and doesn't meet the formatting requirements and obviously

proofreading and spell checking and stuff but that's it that's all I check for yeah but the first one currently I I agree with you 100 both case and then in the first one I'm I think you mentioned that you ask yourself when you're reading a draft that does it need a communication between multiple adopters right and if that is the case The Proposal here is to actually write it down and then tell authors what it means to require the 4A ERC to demonstrate that it needs to demonstrate to different adapters and I think that's that can be a hypothetical argument it doesn't need to be you need multiple reference

implementations from independent parties it just needs to be you need to write your motivation who you think the multiple parties are going to be and then that's it I think that's pretty subjective if you anytime like I can anyone can show up like just like use I'll play The Devil's Advocate um just like you said uh anyone can just do chat gbt three times or and Implement them they can very well just argue on their ERC says hey we are three of us and then we need to communicate with each other and then here is the ERC so that renders that that's the same that applies the same to yourself I think that's like that's not a civil attack

though it's like if you can construct a scenario where multiple parties need to talk together about a standard even if they're the same party like it doesn't matter because it's hypothetical if there could be three parties that need to talk together about something whether there are three parties or not you can standardize it um I think that's yeah I think I think that's um I I hear you I hear that you uh you think that um it's so long as they want to communicate themselves uh they can and I'm just going to feel that it's very uh it's not demonstrating soundness and usefulness as as far as I'm concerned yeah so I think the real problem you're

trying to solve and you know forgive me for speaking for you here but is you want to improve the reputation of erc's like the process itself right you want erc's to meet a higher bar than they currently meet so that people trust ercs more whereas I I would like to keep erc's like we just publish whatever people send us for the most part and other people have to decide the quality and I think that's the root of our disagreement is that roughly correct I think when you apply that to the link requirement that seems not the case right so linking requirements formatting of the documents those are all things for like um they are for the process itself like

we want to guarantee availability but we don't guarantee soundness so we we choose what we we guarantee I think so yeah I I think if you lay out that um you think that ERC can be meaningless or the meaningfulness is where reader generator who don't necessarily adopt them who don't necessarily use them to to judge where I generally believe that in erc's uh needs to be adopted to be meaningful um I think if that is the characterization of our differences I agree I would be happy enough to see

um a requirement for one implementation and test cases to get from after um it's not the editor's job to actually doing the implementation could be wrong it might not actually pass the test cases it's the review process that that's that's part of that yeah and passes the test cases and I I don't really see the need for multiple implementations I understand that would increase usefulness but I'm happy to

treat usefulness as a different issue and I'm not sure that multiple implementations really helps out a lot and it's a lot to ask is sorry team teams teams don't really want to implement something that's not already you know a standard or close to it it yeah it's just a lot of work for for no purpose um so you could have a group of 10 people who say yes we really want to do this and here's our implementation and telling them go find two other groups to

implement it um it's [Music] that's perfect yeah I I see I hear that you um you you are happy to see one implementation and you don't well you think it's too high to ask for multiple implementations um is it okay that we say that uh having one implementation from draft to review is consensus and then we don't have a consensus about what it take to move to review to last call I'm more okay with requiring one but I'm I'm

I guess I'm not strongly objecting to requiring one um but I'm not in favor of it so you're neutral basically you're not you're not blocking requirements I'm not blocking but I'm I'm slightly negative on requiring one okay uh uh okay yeah sounds good uh and uh I saw that uh Matt says three for last call is too high um not you have any concerns for um for requiring one from preview to to from draft to review I mean what do you mean by require one like do you want to change the ip1 to say all ERC type eips that want to go

from the status of the status have to have one uh reference implementation or like where does this yeah I mean I feel like this should just be imposed by yourself and you should say like I would like to see like a reference implementation before merging this to review and if the person says Ah that's not in the ip1 or I don't want to do that for some reason then just let them go through uh so make it a suggestion and not a requirement make it yeah not a must is that make it a should that rather

than that must yeah yeah sounds good yeah I will make it a suggestion can we make that suggestion into eip1 I think if if we want to go ahead with that it would be better to be reflected in eip1 but we can also maybe learn more about it um by if you can create a pull request there and see if there is any strong objection to that because this discussion is here in the closed room when we have a pull request open probably people will come and add

more feedbacks sounds good I'll create a pull request for everyone yeah okay I I'm happier with must but should is is strong enough and we can we can wait to see what our experience with that is the move it to must if it really does help I think it will thank you it will improve the quality of Steve and it will um help with just the sheer number of them we've been trying to deal with and certainly be a better solution than

splitting the repos and other such sounds good yeah I totally agree all right so we are at time thank you Victor for sharing this I hope the recording of This will be helpful for people to follow the discussion as well as why we are reaching to that kind of consensus and um when we have the pull request we can probably take it from there um we have just one minute left I would like to have attention of editors for the pr number 7077 what people think about getting it merged I mean if there is any strong consensus

right now I'm in no objection it can be merged but if people think that it needs to be discussed because this proposal is already final um we can take it on the pull request um I think I'm fine with it it's just formatting changes and moving a bracket to a new line um yeah I don't have a problem with it okay anyone here objecting to that okay fine as well so yeah if someone can maybe merge it because I I don't think it's blocked by author it's just that any editor may have to merge it uh it'll need an author approval oh it

would okay perfect cool so I will add that in the summary as well thank you everyone for joining and I have added the month summary for EIP editing sorry EIP is inside we don't have time to go through it but people can check the link added here in the agenda thank you everyone for joining us here today I hope to see you in two weeks have a good one everyone thank you bye