EIPIP Meeting 84

Transcript

welcome to eipip meeting 84. this is a issue number 245 on ethereum catheters GitHub repository have shared agenda Link in the chat we have few items to be discussed today the first one is uh open Issues new open issues and pull requests then we will have discussion continued or updates from the past meetings followed by some updates on eips insight and editing of this hour starting with the first item here um that is with respect to a meta proposal 7199

the first one added here is an issue it suggests that make eipw only check change line except for changing status looking into the issue it looks like this has already been responded with the pr 7199 just wondering do we still need to discuss anything we would like to uh you know come to a discussion any further or is it good and can be closed um I I see this was proposed by Victor Victor if you have to add anything on this one uh no

very well um so looks like the other two PRS are also related to this the two PRS are seven triple two and seven two two five the seven triple two suggests that uh 7199 proposal 7199 should be moved to review and uh there is another PR opened by Sam Wilson which suggests that it should be moved to withdrawn the first one is by Vector Victor if you would like to share your thoughts on that and then we can look into the proposal for Sam proposal by Sam I'm open either way so as there is very

updates um it can be in if you want and I can move it to withdrawal if if we modify the ER if you want yeah my objection to this is I mean both procedural and content but my procedural objection is that if we have every policy decision in its own EIP we're going to have a ton of little scattered Apes with policy decisions and I'd rather keep them all on each one um what do other did editors think of it or yeah I think this has been plot many updates

so ideally it would be um it will be fill out I don't think this is every small policy because um it just happens so often so ideally it will be spell out I wonder Matt or Greg do you guys have any thought on this which PR should be moved forward all right talking about 7199 that's

right yeah I mean I think it should be withdrawn there's that for a like you just screwed with the content or you disagree with having a meta Eep for it I yeah I disagree with having him but I eat before it yeah I'd rather it go any ip1 all right so if you wouldn't run Victor could you make it as a PR to eat one and then we can discuss on there okay much appreciated thank you

all right uh we do not have any changes to final proposal as the next item however I'm still wondering uh if we have the bot issue got resolved looks like there was this PR 7240 which was approved yesterday in the EIP editing office hour uh to be moved to final but uh that hasn't been merged yet I haven't heard any updates on on the bot situation from Panda um so the authors they were inquisitive about if anything has to be

done and our general recommendation was to wait till the bot gets activated and it merge all by itself I hope we stand good there moving on on to item number two which is discussion continued or updates from the past meeting um so one big item that has been listed here is EIP ERC repo split uh for people to have some context we have been discussing this topic for a few years and there has been significant progress in the past two weeks Matt opened a PR for repo split and it was also discussed in the last all core Dev execution meeting

from the ACD meeting it looks like most of the client deaths are in favor of the repo splits oh if that's the way forward we must discuss next steps uh there is a hack MD proposed by Victor which is also added to the agenda here we can take a look into that and uh yeah opening the flow for people to discuss this topic and propose next steps for us um Johan if you are speaking we are not

able to hear we can just oh no sorry I was just screen sharing for people that aren't for whom it's more convenient than opening the heck would be right okay oh sorry I should probably introduce myself I'm just a random guy who uh is trying to help I I don't have uh a strong opinion on this other than I would be more active after the split in one of the two editorial boards that's all um I don't know Victor if you would like to walk us through the document and talk about the major points that you propose here

that was uh that's more than come up with so I guess whoever added that can comment I just list a few tasks feel free to add more I just indented suggestions under each of your top level points so that uh here maybe it's more visible in this view the numbered points were Victors and I just gathered comments from various places and threw them in there so maybe it's worth going over the high level ones and ignoring all the stuff and then zooming in on the one at a time if people want to add anything or subtract anything does that work is that

works well yeah sounds good so who on if I understand correctly you mentioned that you would be interested in contributing to the both side of it um yeah anything specific you would like to add here you mean you would be helping out with EIP 48 days of course yeah please go ahead and share that yeah sorry I mentioned in one of the GitHub threads I can't even remember which but like if these were distinct editorial boards I would love to be an editor and volunteer whatever

the minimum hourly time commitment is to be on the board for the non-4 ones like I really don't understand how clients work I'm not you know the rest or a go wizard um but I I think that like but another way what I'm most interested in is having the real world processes around like the editorial processes split um the specifics of like the repo or the the documents themselves to me is like a secondary concern so like if there's consensus that's putting the uh editorial duties between two editorial boards if there's contents

there like I think everything else is detailed and I'd I'd love to Champion whatever details get contented right sounds good thank you yeah there's there's not consensus and there never has been yeah maybe that's a good place to start sorry I'm coming in apparently years late I don't know the backstory so please help me uh understand what the sort of blockers are to consent this other than your most recent comments which I read

um I've never been in favor of splitting the process um I I submitted changes to eip1 uh I thought they were on the agenda I don't see the point of splitting until we've actually looked at what the pain points are and I simply haven't seen that the split actually helps the pain points and the pain points I can identify I've suggested how we can address those without any split um that's at this point we're kind of overwhelmingly in favor of the split it's basically you and Victor and Sam

who are against I haven't seen any one from the community opposed to the split so I think at this point we just need to go forward with it and solve the problems on the way we operate by consensus not by vote and the community has come to consensus that they want this processes to split the editors have not the communities the editors have not come to consensus it will do damage to our process to split these I'm convinced of that okay we're we're going to go forward with this split because the community has already said that this is what they want to happen

if you want to continue then I am no longer an editor that's the price you're paying for not getting consensus from the editors so one thing I'd like to point out is that we're really starting to move core EIP processes outside of the IP process there is no EIP for the execution engine API um The Meta eips for uh the hard Forks are no longer kept as eips are kept in a separate repo a lot of the Json RPC stuff is done outside of the EIP um and a lot of these is the community just doesn't um they don't some of them don't respect the EIP

process um some of them find it cumbersome some of them refuse to interact with it and this is a step that would help um adjust the rules for the courts as contributors versus the application layer contributors so that we could change the rules that have slightly they have very different audiences towards what a court process needs from an EIP than what an ERC needs from an EIP and splitting it'll make it very crystal clear that these follow under different rules rather than having different views within the editors and different processes but I think the big problem that we need to address is that this split is already starting to happen and if we don't take action soon it will continue in a way that will fundamentally change eips in general so

we should try and direct it to a net positive solution rather than have coordination failure and let it move away from it and destroy an existing institution I think we need to come to consensus to try to make things better but just refusing to acknowledge that that half of the client the half of the the client base that is using the EIP process wants the separation I think and is is not a net positive solution I've I've suggested a series of changes to handle a number of the problems I'm aware of I haven't seen I've seen we want to split them but then what I haven't seen if we split them

these are the ways in which they're actually going to differ I haven't seen any ways that they need to be different in order to solve the problems because the problems are affecting both sides in the same way um I mean for one the thing you've proposed are things that have been proposed for years and years that we haven't actually been able to integrate into the processes so I'm not really optimistic that this time is different we're going to be able to change these things but I think ultimately we need to show that the community that we're willing to make drastic changes and help bring some people back into the fold by showing

them with this process split even if there isn't something that's like materializes immediately off after the split right now they're so disengaged with everything that they're not even willing to interact with the processes with you know minor modifications to things well a big one is if we're not willing to change our link policy we're not we're not going to get people to stop complaining about our link policy which they hate I don't think it's worth like going into these complaints right now we've already kind of decided to move forward with this and if we have not decided we have decided or the editors if the community

so-called can simply tell us what to do I'm out of here the point of being an editor and of these things if it's not to serve the community if it's not to be a place to improve ethereum through the communities like needs I'm I'm trying to I've written a PR against eip1 that goes through the things I think are wrong and ways to fix them we've had three or four years to do this and we haven't been able to do it so I think it's time to try something different so we split them and then what how does the split actually help a damn thing

have a shorter list to review rather than reading every random um application layer business model that thinks they need an EIP so that's one material advantage that splitting the repos will have to core developers in the user interface for GitHub you simply pick a label and filter out that label as far as the emails we the bot sets the titles so the bot can put a label in the title to make it easy to filter we can create all kinds of fancy ways for people to better differentiate the different types of eaps but at the end of the day this is not how people interact with GitHub repos they're used

to their repos having all the things that they care about and they just use the standard notification tool they don't use labels they don't use email and we've seen for years we've had these RSS feeds nobody uses them this is the only way that we're going to get people to interact with the repo that's just the in the story they can't be bothered to hit the label button in the GitHub user interface you can't get no notifications by label yes you can you go up and you hit the label and you say t Dash core number for notifications no we we need to Simply fix that so your email filter pulls out what you want I don't use email for GitHub most people

don't use email for GitHub we just go to the GitHub notifications Tab and review what's there um containing into very specific points of notification pane I I know that's a like line you use notification um I don't know if other people I don't I personally that's not my experience and also I haven't come to know a handful of people um near me who doesn't so I don't know how representative that is I I think it's worthy that uh we go through some of the policy proposal um that um that um

reg list out and see if that is where you want to go it's it's worthy discussion even if after the splits and for the record I personally have reservation on this and then I don't wanna I'm not saying that I'm going to block consensus but I do think that um what Greg has list out as a proposal deserves a chance to be seen here and you can see how much um improvements um or agreement you have in the future of policy and if you don't even the good the the positive thing is that if you see that you will agree together I I mean uh that's uh the

policy where it will go then split split makes sense but if you cannot agree on a lot of policy um maybe that's time for discussing it so um maybe we don't see what Greg proposed in additive VIP one as directly related to ER the split but maybe it's just this deserve a a read I've read it and these are just a lot of things that we've talked about in the past and we haven't been able to make this process use for useful enough for people so I think that we just need to move forward with the split and discuss

policy changes after none of these changes require a split where were they in the last three years I've been discussing them for years I put them out there exactly so this is another PR that's going to sit here for years while we debate like what how it should go in how we should change it I put it on the agenda for today that's why yeah we've had on the agenda many times how to improve like getting eaps into draft like what should that look like should they be numbers should they be letters should they be EAP eapd like we've had these debates debates have gone nowhere and it's time to just throw the white flag up and split these

processes and then try and resolve after these things subtle I remain convinced that splitting them will do real harm and will not help what I'm curious to understand like what harm do you see coming from this because um and and like I understand Sam's Point that's like look the repo is like a collective documents you can treat different documents a different way but obviously we have different types of documents in different people today like the yellow paper eels Json RPC they all live in different places so like what's the what's the harm that you see from splitting aside from like sure it's going to be a bunch of work to do it the first time um but yeah beyond that like assume the split is done you know what what is the

pain we're experiencing after on like an ongoing basis are we going to create two organizations to go with the split or is it just two different file cabinets to deal with what do you mean organizations I'd like to unders the split is just seems to be creating two file cabinets for some purpose but what do you mean by organization do you mean specifically EIP editors or something else yes I I suspect the process to add and remove VIP editors it might be the same process but the people might end up being different and potentially overlapping so maybe you know if you say something different than today right right yeah yeah but yes I by I think our

organization is maybe like implies too much overhead like it's not like there's like a a company or like a a literal Organization for those things um so I yeah what are we actually going to do differently after we've created these two file cabinets and gone to all this effort but what is the thing that you're worried about happening like you keep saying that this is going to create something bad for these processes but you're not really enumerating the issue nobody's told me what good is going to come of it I I mean we did we told you a very

specific good thing that we'll come up with the court of developers are asking for which is that they can actually use the notifications for the eips whether or not you think this is reasonable like I can't make you believe that that's something that's useful but that's like a very small specific thing it's good that's going to come from it is it's going to be a lot easier to get people who disengage from the process to re-engage with the process like has been mentioned in chat we have been losing specs that should be eips to other repos that are skipping the EIP process that should have EIP numbers posted for these changes but rather than engage with the EIP process to create their own repo and do their own thing that's the big win I see is by splitting the focuses of these two filing cabinets these two

organizations or however you want to view it people are going to be able to laser focus on the area they care about and not have to worry about the other things that are outside of their skills of concern ERC is an application layer eips have a broadly different scope than protocol level changes and there's very little overlap and when they do overlap it's worth an EIP in both repos because there's going to be different aspects that impact how the protocol interacts with it and how the clients interact with it so that's the big change I see is making these two layers much clearer and more distinct in development and testable developments and processing uses so it's going to make it more crystal clear that this happens on the application layer and this happens in the protocol that is the single biggest

game I see from splitting this and I think alone is sufficient to split it okay well I mean I'm sorry if we do this I'll leave I'm free to leave you're free to let me leave and I've I've gone through the changes I actually think will help I think the same changes need to be made to the ERC I see the same problems with the process so splitting the repo still leaves all those problems there's some notes go on I I I I don't think many people

disagree with you that there are many common issues and the many things that need to be addressed but this is an orthogonal issue we're trying to address here and very much would like to to to fix many of of the things you brought up and in many of the ways that that you're going after here but this is something else that we desperately need to be like would this be help the erpv process get more used foreign and having two processes over time why have them diverse because to people who aren't actively involved in both processes and don't

um uh don't don't actively all of the exact weird rules you have to learn to interact with this repo it is a nightmare to to come over to this Reaper I see it and they are uh like it just seems like a very confusing tastes to to to exist and we can do this thing where it like dramatically simplifies things with the average person you just have to go to the repo and look at the things that are probably relevant to you and you can then start filtering by topic instead of figuring out what the mental filtering mechanism is that uh happens to the interact with this report this this PR doesn't suggest changing anything about the process the people are complaining about

except except getting a smaller set of notifications and making the the reaper itself easier to interact with but like again no one here is pushing back against other the other changes you're proposing those should also be discussed and implemented I think people desperately want more changes so let's just do that first I think for years and years so I'm gonna have is there going to be two EIP ones what are we actually splitting here the places where these these these um erps exist and potentially the

process is slightly over time if that's what the demands are from the two different communities largely they're interacting with this process it's only one community but that's another way we should be using one filing cabinet I feel like we should try and time box this I think we're just starting to go in circles now okay yeah can I can I ask a question I put something on the agenda that's that's not getting discussed so we did discuss it hardly because I can I can I propose to also ask that we've seen um

or tabs and you're definitely welcome here but uh I I have heard your voice uh can I ask audit and like Lion who in the editor group is strongly in favor of splitting the Gordon in the chat says he's struggling paper uh Gordon sorry maybe I we didn't but uh I've not

work with you um maybe you three three times mine um no I don't think this name was ever in their latest list if this question was specific to editors um no I don't think it was there and we are not joined by all the editors today in the meeting that is another point to be considered so I'm not sure if we can get a proper response over here I see um Panda and for gender saying not in the meeting I I think we we don't have all the editors just like we don't have all the coin devs here as well but I've seen

that currently it seems to me only like clients it's in favor um and uh so it's gender is in favor um yeah yeah it seems like there's a a bunch of people who are who are reserved and I do believe that um um the the problem that carback and Daniel and uh uh Mary is said is real problem um that people were disengaged and notification was not um was inconvenient for me the notification is more is inconvenient but the more problem is it's so hard to edit and what's I think um what eip1 updates by uh Greg is about

making it convenient and if you discuss you will realize that a lot of things that you believe is natural are actually not like some people in the editor group are actually trying to say that oh let's make it harder and that's what I think um we are trying to repeatedly um Greg and I and and a bunch of us are trying to make the process easier for people to engage and we're frustrated as much as you are we feel that the discussion has not been made to make the progress and most of the deck core devs are not as closely follow the debate of policy as we have been and we don't know how to service those those debate to you on the better way

um if a lot of debt core devs like individually come to us and say hey this policy is really dark we should fix it and whatever we take it to the editor group it gets blocked um I the the frustration I've seen is that those are from both sides people just don't want that to be so restrictive and we haven't been able to resolve it and I'm not I'm unlike Greg I'm not planning to block the split I just feel that's um which we really really should discuss and take the input from the core Dev and ERC authors that how how to make it's easier for us to add it and uh I will say other than a notification I haven't seen very

convincing things that a clear direction of why uh or how or can uh can benefit a policy that ERC can't in the point and yeah so can we at least take a look at um the IP edits up um updates of the of Greg's and then I have Greg maybe walk through the the over overview of it and and see because we it is a valuable time where a lot of eyes here are today you can see the The Proposal that we make and see if it makes sense for you yeah I see uh Dano has some points to make on protocol specific policies

please go ahead Daniel so there's a couple of things that would benefit if we could split the repo that we could even have the discussion about starting if eips and erc's were different some there are some workflows that the cordovs have adopted um such as eligible for inclusion included in the hard Fork that that kind of used to be in the MP process but we pulled out and these are steps that are completely inappropriate for an ERC to be considered as gatekeeping we shouldn't be have to keep the diamond standard because clients don't have it implemented for for Cancun or Prague or whatever so that's one policy change that I think we're going pretty early is we would bring back in our signaling for which eips are actually viable and which ones aren't for inclusion the withdrawn suspended just really isn't doing it for

us we need something that has feedback that is more tightly integrated with the ACD process um and the second thing is I think we need to add another step for eips that our core protocols that reflect the the Readiness for testing development do we have reference tests written for these that should be a separate lifestyle cycle stuff that should block final acceptance of these tests and we should also agree in the process whether it's ready for testnet if it's been deployed on mainnet these are things that are very very peculiar to core protocol and aren't worth discussing while we are still merged with um the the the ERC process that has completely different goals of completely different agendas than what core developers have it's these vastly

diverging policies of the vastly diverging needs that come from what people want from the ERC process that is really what's freezing the gears in all eip1 discussions on the thought that it needs to serve all possible use cases if we split the repos based on use cases we can go we can have more reasonable discussions about specifically forming and changing these policies that we just can't have when it is an all-commerce type filing cabinet just as little as two different filing cabinets will make it easier to even have these discussions that we just can't have today because people say well I don't understand it and don't call into the meeting so I definitely understand a lot of the frustration with having the EIP process not attached to the cord like the core

development process like well well I was working on eels the amount of times that it's like okay which hard Fork is this EIP in and you know what block number does this EIP activate on um I understand a lot of those frustrations and you know switching from my eels hat to my editor hat um the statuses of documents and Eels are of the documents themselves that I think the reason and this is from before my time as an editor unfortunately but I think the big reason why um we aren't more tightly integrated with the release cycle of mainnet is that eips are meant to be uh like agnostic to the chain that they're deployed on so you can point to an EIP

and say like you know on ethereum classic we have these eips and on on mainnet ethereum or test net ethereum we have those eips and like that's kind of why they're they're so separated from how core development Works maybe it's time we re-examine that link but um we can do that without splitting the repo I think like having a different process for core eips is completely doable uh I would also like to add a few points here I think there is some misunderstanding I'm going to clarify the existing EIP process is somehow different for core and a rest of the proposals rest of the category in time so uh for core eibs we do have the

process of CFI which was never a part of ERC it was never it's not part of eaps though that's outside of the EIP process that is a part of network it is on the execution specs it's added there okay that's outside the EIP process right what I'm suggesting here is like we can still follow that and it is not affecting core eips to follow it and it is I mean like erc's are not a blocker here the process what is being suggested can be followed we have ways to follow and I

don't think ercs are stopping that ERC and core EIP process in fact core EIP is only category where it is a little bit different than any other process for example core EIP should not be moved into a review status unless it is into CI devnet uh phase like client have started testing into it we cannot move it to a last call unless it is on public test net and these are not the restrictions for ERC or any other category for any other category we say last call is only for 14 days but in case of core eips it can be seven days to a n number of days till we put it on the main net so we already have

different things in place for core eips we are already making it an exceptional category where we are providing special privileges so what I understand from this discussion what vector and Greg are trying to communicate is let's try to point out the pain points which are not accepted by the ERC category and which we want to implement because we want to support core eips here in this repository I do agree that the noise point is very much valid the notification point is very much valid and I I perhaps do not have any perfect solution for that but if that's the only consideration for the split I don't have much much to add but if we have other

pain points that can that we can address I think it is not only going to help core EIP process but to all EIP process for that split may not be required we need to understand the issues here so let's look at the CFI process um that's something that does not really managed by the by the EIP process that's something entirely managed by the ACD so now what we would have to do is if we want to change that we would then have to post an EIP to eip1 let a bunch of editors who don't always call into this meeting um then we have to represent what the needs of the core devs are and that just increases it increases a lot of friction to an already slow process of shipping core protocol changes um and as we've seen when you do a

proposal that someone doesn't like they will jump up and say I'll block consensus or I'll resign and make big drama out of something that should have been a simple change that is my concern of keeping it together really making all of these exceptions but the number of the exceptions that we're getting is to me a signal that it needs to be a separate process the filing cabinet should be generally all Commerce to all and have all the same rules if you have more and more exceptional processes for subgroup then I think that's very strong signal that subgroup is not being served and is not appropriate for this particular regular funding cabinet um some history here we started out with nothing but drafts um and how the court devs organize their own process was not an EIP concern once

something went on the main net we labeled it final because once it was on the main net it couldn't really be changed uh whatever was on the main net was what was on the main net and that's what the EIP needed to describe um we added a last call process for erc's just so there would some way to get them vital for people to say okay this is what we're going to implement over time we wound up adding more categories and process and sort of mixing up the core Dev process and the EIP process for my from my perspective as an OG it got more complicated it got

more mixed up together so yeah the core devs are having to fight with the IP process we when really they shouldn't have much to do with each other the core devs could organize where a draft is in their process pretty independently but you can't this and and I mean the fact that like it's too launched without using the EIP process shows you that like this doesn't work in practice right like and and the fact that you have to create a process out of this band just like adds way more friction like when I have to send someone the CFI definition and it's some random thing in a repo somewhere like it it just feels like

it's terrible like when we have to use each magicians uh to like signal which like eips we may want to include in the hard Forks it's like we're creating all these random things that the only people who can actually track our folks like basically me whose job it is to do that but if you're a random person who wants to figure out hey which gips are being proposed for Cancun you can't go to like eepsod ethereum.org and have any in Insight on that and similarly you know on the ERC side if you're a random person and you want to figure out which you know uh what what are the implementations of like the last nft standard you can't do that um and you can imagine like that would be a much healthier version of both those processes

um like yeah like Peter from Death asks me for these random documents you know from time to time and it's kind of insane to me that like you know with the context he has he's not able to like into it where the right thing is and I think this is because the the things have to be standard and I understand that like it you know you don't want the EIP statuses to be focused on hard Forks because not all of them need hard Forks but if we do split the repos then you can say look on the EIP side there's an extra tag that says you know hard Fork status or something like that and you know maybe for networking eips it's just not set but for like a core protocol change then um you know it gets set and then you can just click on like the proposed tag or

the included tag or the London tag and you just get a full list of all the eips in that Fort and like I I think there's there's some aspect where like how do we make this easy for people who have very little context about the whole thing because like even with folks that are you know on quite literally the gets team that work at the ethereum foundation they can't figure out how to find stuff and this means that like if you're a random contributor who just wants to come and like write their first EIP and make sure it gets seen by the right people and you don't necessarily know you know Peter or me or Marius or someone that can like help you through the process um then it's it's like really bad and it

puts those people at a disadvantage so I think the more we can do to keep the processes encapsulated in one thing the less context people have to learn and because there are some differences with eips and erc's it makes sense to split them so that you know both processes can eventually reflect like the reality of the whole life cycle of not just like writing the spec but like writing this back and getting it live in deployed and stuff like that I'm in strongly in favor of like keeping both processed encapsulated and keep on working it looks like the ship before uh stopping the repo split has already been sailed and I think it will be interesting to follow on what on the next steps uh yeah please Marius if you

have to add something over here yes so one thing that I would really like to talk about um is so as codiffs I feel our duties with the community and if the community wants uh something or doesn't want something we have to respect that wish even if um the community uh wants something that we are not in favor of so for example I was part of uh brockpo back in the day and um I was really in favor of it and I thought it was the the right thing to do and at some point the community decided that this is not the right thing to do

and uh so I had to accept it and uh I think the idea of the EAP editors overruling the um the community as something that is so foreign to me um that I think it's incredibly Democratic why why should these eight people have a vote on um how this process that should serve the community and doesn't um uh why should should they have to vote at the vote to block the the view of the entire Community that's I haven't seen

anyone except for uh people from the EAP editing team speak out in favor of keeping the repositories together that's that's it thank you well so like I said in Chad the community would rather have you know way higher gas limits that would cause you know database problems in a few years right the community doesn't always know that you know the technical reasons behind why things are the way they are and I'm not saying that there are technical reasons to keep the repositories together don't get me wrong I'm just using that as an example of why the community might not always be correct and experts might be you know have a different opinion and you know a lot of the times with the process around eips I think they have very logical reasons

um and I I think a lot of the hate the EIP process gets is from you know the previous era of EIP editing and that we're a lot more like we're a lot easier to follow now than we used to be yeah there has been a lot of process change and I do not deny that um I think it's time to accept this as one of the process change and uh one reason why I feel like EAP editors have been strongly supporting or opposing whatever their point of view they are sharing because ultimately Process Management is something that they are heavily engaged with so yeah considering that the split will bring as I mentioned that there would be a fixed cost of

having this split done let's start looking into this cost and uh if I understand correctly it was mentioned in the all code execution call that if this thing does not work out we can perhaps come back and make things back as it was I think that there would be some tooling needed um I was having a conversation with uh someone and he mentioned that we can we do need to duplicate some of the work let's start looking into that um I don't know Sam you have been managing more most of the parts related thing you think that there would be some challenges that we should perhaps discuss here and try to find out the solution to that in case we need to uh

move forward with this like um as far as eipw the the validating bot goes it would maybe be like a couple days worth of work probably a little less to um make it like configurable of for split um it shouldn't really be a problem for e review Bots I'm a lot less familiar um but I I don't see it being more than a few configuration changes all right so just imagining this as like a cabinet changing for ERC and eip's we do not see a lot of tooling issues is

that a correct understanding they can perhaps manage it yeah so the tooling should be easy um the governance overhead might be a little bit worse but I don't think like I don't think there's any like having to do a ton of work objections to splitting the repos all right I do understand that there are people who are still not in favor of having this split and I heard um Greg mentioning that he may be willing to resign at this point of time I would sincerely request to every editor please do not resign we need you I understand there can be objection and that can be solved and that can be

helped only if we have you we only have six editors on board and we need more people to join in to help out with this process split whatever time you have got if you can divide it for both repositories that is good to have if not then please support one repository and we'll try to have more editors on board on the other repository as of now this seems like what people are requesting for or looking for let's give it a try see if this helps and if it helps the core EIP process to evolve better ERC can always learn from core EIP and have the process adjusted other than the

filing cabinet filing issues I I hope that ERC group ERC Community does not feel a lot of you know pressure because they are less with editors or they do not have people to support we are here to support we will try to support both both groups having said that yeah correct yeah I was hoping for you and Victor to jump in and say some concluding words for this topic I have I have put a proposal on the agenda that we have not really discussed it I've been told well we've already discussed those things and yes we've already discussed splitting and we

haven't really gotten to a consensus on either one I'm simply we have a consensus on splitting we're kind of asking if you still want to be a part of it if we go forward with this I'm blocking consensus until we have a complete plan really I think it is a sec I think at this point you might just not be part of this anymore well I have asked I have asked to um have an opportunity to surface this to the ERC author group um and uh I I was hoping that to get a chance um when I heard that the ERC authors are not part of the community I was a little

bit confused so um when lifeline and says it's a community consensus I was quite um confused because we haven't asked the ERC office and it is totally possible that when we go to ask yeah the authors they want to split as well it's totally possible is it just that um it seems I posted it on Twitter consensus was well uh it seems like the consensus what you meant is not as mature as I would see it they had an opportunity to say that this is not what they wanted Tim posted this on Eighth magicians in February this PR has been open for over a week there's

been a lot of opportunity not a single ERC developer has said that they don't support this so at this point like there's just nothing like there's no point in continuing to drag this out do you what what is this please please what's the objection to simply saying I want to see a complete plan not just we're going to split them but we are going did you have you read these hacking at the hack MD have you read the pr yes there's the plan we're not going to enumerate every possible permutation this plan because then it's never going to get done we just need to go ahead and do it this is

like the rough outline of how it's going to happen what is the first rule change that's going to happen in the core eip's repository and the first rule change that's going to happen in the erc's room I don't I don't wanna I don't think we should be going into like the specific rule changes like we no I've already one example it doesn't really matter we have six minutes left I think that we need to like sort out how this is going to go down because we need to come out of this call saying yes we're going to do the split because we can't continue to drag this on forever I have a PR out I would like you to be considered seriously it's not going to be considered before the split uh

sorry if you're not going to consider my EIP that I'm not being retreated respectfully and I'm gone okay uh Greg I really want to be respectful over here I really want to be respectful over here and I would request you to move the pr in from draft I mean like it is still in the draft and uh we don't know if it is ready yet if you can change change that make it like you know the pr is ready to be discussed I think we can perhaps have more discussion on that and as Victor also mentioned that he would like an opportunity to have it discussed with the all ERC Dev meeting we can listen to uh what people over there have to see

what we want to do here right now to get prepared for both sides like if the split is happening then we should be ready with tooling we don't want things to break down so we should be ready with tooling which I suppose is in moving in the right direction we should do not have to work too much it can be done I also manage a website called eips insight for now we are already taking care of like you know every data coming up from this eaps repository if we have to go with the split then we perhaps will have to have another set of tooling done for that thing definitely we have to do a lot of work what we are um I think concluding here is we should be ready for going in up both ways we would

be discussing the changes that you are suggesting for eip1 if it is valid for core EIP what we need to do is like suggest it for both parties and see we can discuss it over there but let's keep that pain points that you have mentioned uh separate from this um repost plan I do agree uh about uh you know the ideas to learn how we want to make changes what are the proposed changes it would be really interesting to learn but in the meantime my only request to you would be please do not take any decision in in rush let's give it some more time and let's see that uh we how do we evolve with it let's be ready for both sides

I think or past that point like I'm going to continue forward down this path of executing the split because this is what the community has said that they wanted right I don't want to lose any EIP editors in this process but we can't just sit here and debate this every call for the next six months no it's already been talked about for years and years This is the End Matt my only request is do not mush the pr just as now as a Victor requested for some more time we give them the time to come back with whatever decision they have as we gave it to code Dev let's give it to core uh ERC Dev as well they had their time they had since February they have had years

I'm not going to merge this PR until we have the Bots ready but we need to start working on the Bots yes of course and I'm we're not going to listen to more debate about whether or not to do this no totally I totally understand your point here so let's let's move that let's get the ready let's prepare our repository to be ready for whatever case we go and if everything works whatever case we go let's give it two more weeks I'm not discussing it any further but what I'm saying is let's let's be prepared for this give us some time to get prepared uh maybe by next meeting we'll try to

collect some async feedback from Panda on EIP bot for eipw Sam already mentioned that there are some work to be done and that should be that should be good um and I hope that by next meeting we would have everything in place and we can smoothly merge it I am not saying Greg we are trying to disrespect you here it's just that um there are some times we go by the majority of what people say even if we do not have an absolute consensus we go by the rough consensus and if that's what people are looking for even if we are having a different opinion let's give it a try so we're not willing to consider my Draft before we make a decision on

splitting the repost is that what I'm willing to absolutely okay you what you need to do is like okay PR is currently in draft so if you make it yeah I'm sorry I put it in draft so that the bot didn't accidentally merge it which no no we appreciate it yeah it would not so if you make it out of the draft then perhaps you will start getting more comment on it because then we considered that as ready to be discussed right okay I've had this these are orthogonal things though like going through the proposals that you're making Greg and doing the split we can do these in parallel like I appreciate the proposals for changing the process but

this is not something that we're going to block splitting the repos on it makes a difference to my block a big difference we're going to go forward with the split even if you're blocking us all right uh I think it's time and we should it could change my block and that makes a difference to me I put many pairs into this into this okay no no that's absolutely true we are really uh thankful for all the time that you have given up perhaps you are one of the oldest editor that we have on board and we would not like to lose you but I think it's time to wrap up and let's have this conversation uh like giving it a beautiful rest we wait for another two

weeks in the meantime we will try to work on the bot side get our eib um GitHub repository and ERC GitHub repository ready for the split and in the meantime Victor will also take some feedback and come back and share it with us Matt a sincere request please do not get that uh we are merged before we have the next meeting see you later all right thank you everyone for joining us today have a good one everyone thanks everyone