EIPIP Meeting 28

Transcript

welcome to eipit meeting 28. uh i'm puchar ranjan uh the first item on the agenda is progress on eip github repo action bot so alita more from the ech team is working on the eip github repo and i suppose she also created a full request to uh you know share this bot for review with the eip editors the pull request number is three three five one uh if there is any other updates on the progress and concerns with the bot that any would like to share any relevance of this effort feel free to share because i don't see anita here but i have seen some comments left by either editors on the

uh issue um i heard it's almost done but i haven't looked at the code myself i haven't gone through the code in depth because we're trying to decide where it should properly live and i am kind of asking for it to be moved to its own separate repository it is just called from eip repository to do the action so that's being worked out at the moment is that how github action works because usually you put the script in the repository in a separate folder let's head in i mean most uh most github actions that people use

are you know public actions and a separate repo and you only add it to your yaml file in the github workflow folder so i assume that it should be pretty straightforward to just have another repository at least from you know what i've what i've seen in the docs for the actions it seems like it has a pretty straightforward method for referring to an action by a repos by a user in a repository name okay brent i believe you you also had some questions on this yeah you guys um have been talking about it it's more related to mine so i'll

just wait till we get to my item and i'll do it all at once sure no problem um the next item on the agenda is network upgrade process review so uh there were some questions comments on the network upgrade process in the all code discord channel last week that surfaced with uh with respect to eip2315 regardless of the decision taking for that proposal i want to address some comments uh that was specifically related to the network upgrade process that we came up with recently so as per my understanding it was mainly related to two things number one many people are still not aware of

the process and number two the network upgrade process could be modified to enforce the review status that is a fairly new status to be a mandatory status at or before it is a cfi approved so for the first point like people are not aware uh i think we need to be a little more vocal about that and create more awareness about the new process and encourage authors of at least core eips to follow the process uh as far as point number two is there i'm proposing some changes to the current process um there is a link in the agenda that people can follow um like i have been meaning to propose

this earlier but i believe it's not too late to start now as well i came up with these suggestions based on some conversation with micah at different places regarding the last call and the final status for core eips so i'm proposing uh this new structure if we can get some feedback on that so um this was uh the oh github issue in the comment right yes i just shared the link perfect okay

oh okay sorry i was reading this mess this comment wrong um you these this diagram that you put into the comment is the proposed changes not the current state right right so in the diagram below if we see that i'm proposing that consider for inclusion could be eip status could be draft till review and devnet phase that we consider the eip status has to be review only and when it goes to main net phase the first part should be review to last call and as micah was suggesting that we should not put final status on any core eip unless it is deployed on the main net so if it is on mainnet then only we provide the status of finance so this is

the proposal i thought we got rid of final or changed the definition to separate the um the upgrade process from the technical process um final still that still exists i think we just it's no longer special for corey ips the only status that we got rid of was accepted that's right i got those confused okay that sounds good so how i think it'll work out is people will wait to to change their eip to final if it's a quarry ap until after it's deployed so they'll probably stay in review up

until they get confirmation all right this is the one that we're going to go with got it okay that sounds good i believe pujo is suggesting that it goes into last call once we once we hit public test nets like once we decide the fourth blocks basically the eips for that upcoming fork i'll go into last call that seems a little bit weird because then if we if there are changes during last call then we'll have to switch client stuff for the fork blocks that have been created right yes by the time you get there you should not have any changes like if you have changes in last call it means you did not do a

good job of reaching out to reviewers ahead of time you failed earlier so that should be in devnet phase uh because if it's in mainnet phase we're it's already so late in the process that we don't want things i mean a lot of people wait until last call to actually like do any final reviews and people put it off so if they're doing that already then wait until the main net phase seems counter-intuitive i think people do that did that because we did not have a review phase we only had draft last call final basically and so there was no like no phase where the author asserted i'm done it's now time for people to look at this before it goes

live there is just like i'm working on this and then it's going live in two weeks like that was the only step previously uh we now added the review step which is so we now have i've worked and then i'm done working on this or at least i think i am i need feedback and then i personally think the last call as um i'm done with this i've received feedback i've iterated everybody thinks this is good this is your last chance to speak up like to stop the ship like the ship's already taken off if you want this last chance to stop that kind of thing putting putting the making it a habit for people to be able to stop the ship in a mainnet phase just seems like the

same problems we're facing today well so the stop the ship would be like security vulnerability like in my opinion once you go into last call it should really your especially core ips should really be done like this should be the like for lack of a better word it is the last call like it is everything is done like there's there's no more changes like this is the last chance for anyone to speak up like speak up or forever hold your peace sort of situation i think we have to me aligns with the uh four o'clock decision we have a precedent for ercs that people can do radical changes during last call because it's happened

yes ercs are terrible and shouldn't be a part of the process so so so the thing is because i love that but because well we shouldn't it shouldn't ideally that shouldn't be the case but right now i feel like unless we really push people to change their definition of last call for both ercs and core eips we're gonna run into this problem because right now the def as the definition and eip1 stands it sounds like you can change it during last call yes you can change it technically um and there's not like a thing that is basically there's nothing in the definition that encourages you to to not to only do security changes

is this a from your point of view is this a uh just kind of historical thing where people are used to last call meaning something that perhaps isn't what we intended but it's what it is or is your argument more that eaps should be final before pork blocks i think eips should be yeah that's that's weird because we don't have a i don't want to add another status in between there necessarily because that's adding too many statuses but yes i i agree that i think the original idea for last call because nick johnson put it in so a lot of people are going off of his definition which is during last call if there's anyone who

has objections they can raise those objections and there's not any implication that it has to be a security objection yes i agree with that um i suspect nick if nick put this in he was modeling off of like ietf and rfcs and all those and those ones by the time they hit their last phase like there's almost never any changes when there is it's really small like it's like you know a minor tweak like a constant kind of thing uh the problem is with ethereum eips we are not nearly as good as those people at making specs and so by the time we get to last call like you said there are a lot of people who haven't even bothered looking yet whereas if you look at uh say w3c you

know when javascript hits their last phase like a javascript change or a browser change gets to the last phase like there's really no opportunity to make any significant changes at that point like it's already gone through years of iteration and it's implemented in every browser and like it's all but done and the that last phase is basically we're pretty confident this is this is it like you better have a really good reason to change the kind of thing yeah i mean yeah i'd love for it to mean that i think that people aren't going to use it that way i think people are going to not know if review means it's review day one or review day 365.

is there a solution to get us long-term to a place where we actually do have a process that more closely aligns with other standards organizations um say um we do put last call for dev net and then we find something in the dev test map that should be worth editing the ap like at that point like if we put in the last call and it was um three weeks after instead of two weeks after like would it be messing up the process to have an eip that's final but we have we found something in the dev test that

that we should update the ap uh so for last calls the review end period for the way i've been treating it is um not optional but it's like the minimum review it's like the early assistant will be merged as two weeks later or whatever date the person puts in however it does not have to go to final exam exactly at the end of the review period specifically for courier piece because it goes final for the exact reason we said it does not go to final and main launch in case there's a last minute change like a bug popped up in public estimates for example oh so one way to fix this then is to have final not mean it's in mainnet

because there are some things that doesn't mean so final won't mean mainnet because it won't require a hard fork final final means that you can't change the ip because remember the erp process is uncorrelated with from the point of the view of the eap process it's uncorrelated with the hardcore coordination process so once your eip is in final you cannot change it like if you want to change it you create a new way yeah with a new number and you know maybe it's copy and paste which is the minor tune but it's a new thing like you don't get the number anymore so if if 1559 was final and we need to change a constant there's you need to create a new eip to make change that constant

it makes the most sense for court efps to wait until they're on main net before they go into that phase because it would suck to have an effect go final and then you're not able to change it because it's already done basically we're trying to avoid i don't know if you guys all remember this but the keck act 256 versus shot three situation where k 256 was standardized everybody thought it was done but it wasn't actually final in terms of standards organizations like whoever does the crypto standards and then ethereum was like okay we're using sha3 and we launched and then like at the very last minute the uh crypto organization what they're called they're like uh we actually want

to change this one little like thing like it was a tiny change but it is totally incompatible with the sha-3 that ethereum launched with and so now we have keck act 256 which is not even a standard it's just a thing that would everybody thought was going to be the sha-3 standard and didn't actually end up being standard and so we want to avoid that situation and so one way to do that is to make it so you know things aren't final until they're live so we can make those last minute changes and not have to worry about running running into collisions and all that but if we do it the way we're currently doing it we won't be able to make those last minute changes without breaking test

nets along the way or having to rush client releases so although like the idea is right like basically the intention is good i think in practice it's gonna be hard to break old habits this quickly so yeah so i can appreciate that and so that's what i was asking kind of is are people disagreeing with the ideal long-term process or is the fear that given ethereum's history and people's historic behavior we're worried that the current process will not equal the process we want it sounds like the latter it is the latter mostly there are some ways to tweak this to correct that i think

one of them being to rename last call um so basically because it's been abused so much just rename last call but then have the real definition be what it is like what you've described um which is very few changes uh except for security vulnerabilities during the last call phase um but then that doesn't solve the problem of the review status being an undetermined indeterminate amount of time um is that really an issue just for viewing not not being for people who want to review at the last minute

people look at so there are some people who look at the rss feed for last call and that's when they start to look at any ip i think the solution here is just having the rss speed for review instead of one for a loss call do we do we know if there's more than one person that uses the rss speed yes either i know two so that could mean that could mean that there are more than two so i i don't know yeah sure yeah i was wondering like if we're optimizing for the right crowd well um yeah i get i guess you're right like because i honestly don't know maybe there's thousands of people that subscribe to this rss feed it's just the statuses is the thing like

the status does indicate like people rushing to review it and then they start to disagree with it even though they're not looking because who's looking for a security vulnerability in the last 14 days i don't think many people are yeah so i think the i mean the real problem here is that in my experience the vast majority of vips gets all a grand total of you know one to two people looking at it right up until a bunch of people need to implement it and then you have a thousand people looking at it and so when a thousand people start looking at it in the last call face then you get a lot of feedback in the last place if you somehow you'd like you're looking at it in review phase like with one five five nine then you get a lot of feedback in

the review phase like actually one time i got the feedback in the draft phase and so like i feel like there's a we have these statuses that are meant to tell give people information but i don't feel like they're particularly functional in achieving that goal like people are not looking at them i would need abuse i would lean toward this to help with the fact that the stat to basically stick with somewhat of the status quo but to try to also push practices best practices would be to keep last calls definition as is pretty much because it doesn't include only security vulnerabilities right now and move it to devnet phase um and then public test net like doesn't

include an eip status beyond um well then that yeah but then that leaves public test net to not have any ip status that's the problem i guess so one correction there would be like minimum of 14 days would be good but you know if we want to keep it in last call for over a month because when it is on testnet uh we believe it is like for four years at least so i am not very sure that we should put the last call status in davina's please yes i would be fine with getting rid of that 14-day thing i've never really liked it personally

okay um that would be okay but like the the thing is i think it's i think the other thing that's messing me up here that makes it harder to find a solution is the fact that that that this definition for last call is the same across ercs and core eips and if that wasn't the case then things would be easier uh we just kicked prcs out of the abuse repository and a lot of my problems too uh if we can get if we start paying for editors i'd be okay with that plan and i actually talked to a project i can't name who said that once um they have enough funding they want to give money for eip editors um so

that's that's kind of part of the another piece of this update i think they don't have any launching a food token of some sort do they not quite no yeah that's unfortunate that would mean they actually have money yeah anyways so i think i need to think about this more personally so if we don't make a decision today i'd be happy with that uh but to think about this more yeah sure and i see there are some comments as well in the chat so uh i'm also okay fine with not making any decision i just wanted to bring it to attention like you know we had this discussion that we are not following the process of people are not

aware of the process or there are some changes that we should be bringing to the process so i just wanted to share it yeah that sounds okay i have it in my to-do list to make a comment on that uh issue uh in the next week turn really quiet yeah it sounds like you're far away from the mic i'm so sorry about that there you go okay so i'm going to keep this item on the agenda for the next meeting as well thanks all right i can just say one more thing on that yeah i think i think a lot of people don't understand the latest eip process and i think that was incredibly clear

with 2315 a lot of people still thought that you know the status of the e kind of meant how far along it was in the um governance process and people were like oh 23 15 was still in draft we thought it was you know we didn't realize was going into a hard fork and you know that's maybe not the best argument in the world there's probably a lot of documentation that was going into hardcore but i think that you know having those things separated caused a lot of confusion for people who don't reasonably closely follow all core dubs yeah i do i'm not a hardware coordinator so it's not my

have my purview but i i do support the hard coordination process requiring that if you want an eip included it's got to be in the right phase like you can include draft database and uh upcoming hard fork i just don't understand what like what is the benefit of separating these two processes because for core eeps you know we're kind of saying that they have to be these things to go into these phases and it's like we've separated two processes but we're still making them force together i think the so two reasons one it's a unidirectional connection instead of a bi-directional so the hardware coordination process points to eips but eips do not

point back and so the eip process can exist entirely without knowing our organization process and that is valuable because of politics the eip process being purely technical allows us to move forward and ignore politics and anytime someone brings them up we can tell them go away go to the hardware coordination process where politics are handled and that's is very valuable especially given that we are already you know massively understaffed to actually do anything with eips and being able to tell people this is not the right place for governance discussion is very valuable i just don't i i really don't see how this is that different from what

because because in my mind the only difference would be that if you want to move to a final state or you know we add a new state that says it's going into a hard fork a new status to me the only difference in what we're doing is that they need to provide a link to an all core devs decision that says you know this is going into a hard fork and then as an editor we say okay yep that checks out i looked at that link it's going to a harder form to update the status and to me that just makes everybody's life easier doesn't make our lives harder um so the we ran this a couple of times with eaps in the past i believe where the governance debate ends up spilling over into the eip process and being very distracting for the ap editors

and the reason for that is because at some point someone updates an eip and it now says you know going into hard fork x going into berlin going into london whatever and as soon as that happens everybody shows up in the ap repo and starts commenting and starts many pull requests to remove that etc when that is handled elsewhere it makes those people go elsewhere when they want to do their brigading and their harassing and harraining and so uh james can deal with that until he quits and hands it over to tim who can deal with that until he quits and has over someone else and the editors hopefully can stick around and not be driven away by the massive brigade and problems that people cause when they see that stuff

like it by having a clearly separate spot for them to go to that's not here like not here not these people don't distract these people they're doing real work go distract those people whose job it is to deal with that problem like and it's by keeping it very clearly separated it makes it easier to uh kind of draw a line in the sand and say no that goes over there whereas if the two are intertwined then it's much harder to kind of stand up and say this is not the right place because they're like well this is it says right there it's going into berlin so clearly this is the place i need to change that i need some pull requests to update the cip that's not going to berlin or whatever that's my that's my reasoning i really like

having the shield basically so so james is able to be a shield for the ip because we have this very clear bucket of responsibility yeah i mean i haven't really experienced that so you know obviously my my take is gonna be different but i can understand how that is frustrating as an editor i think you know i mean i'll just say my two last points i think that one you know if we design the process in the right way i feel like we can use the process as a shield still i think that we should be able to say this isn't the place to discuss this we don't discuss we don't choose what goes into hard forks we just you know if in all courthouse decisions says that the status gets updated we update the status it said

go argue about that in all court devs wherever else i don't see why that's that different than using than just saying this isn't discussed here because it basically still isn't um and and then you know the other thing is that i feel like we're optimizing for you know the five percent of eeps that have a lot of issues and by optimizing for those eeps that have you know issues and a lot of people fighting for them we are really degrading the experience for everyone in the community and for the other 95 percent of eeps because a lot of people just want to go and see you know want to read about it and know what the status is and they want to do it all from a single page and if i it's it's just incredibly frustrating to like look and eat but not know

how far along and the governance process process it is from its from its uh site that's why i think i said from the very beginning that at minimum we should also include as a courtesy what the like hard fork status of an eip is even if those things are still separate the you know the specification and everything so my opinion on the last point you make there is that i think the real issue here is that people are using the eip as the center point and i don't feel like it should be i feel like the eip should be a technical detail not the you know the the the center point and unfortunately this is not how things have been handled historically at all like this this is very much

not how things are actually done uh but i do think that it'd be great if instead of when someone wants to say like you know what is this new feat change they don't go look up or get linked to eip 1559. they get linked to the like that resources page that tim put up it has links to you know some blog posts it has links to berlin hard fork it has links it has description of the erp designed for certain audiences like it's not just the technical specification i feel the vast majority of people the technical specification is not the right place for them to start learning about an eip or talking about an efp or anything like that like it's you know it's one of those things

where you know there's 10 people who actually read the rfc for for email addresses but no one goes to the email rfc to learn about email or to learn about how to send an email or how to use email or anything like that like there's like probably a few hundred people in the world who have ever actually read that ears that rfc uh front to back i would like it if we can get there but maybe i'm being overly optimistic i mean i think that's i mean i totally understand that and i definitely agree that that's probably the long-term goal i just don't think that we are close to that i think that the number of people who are really involved in this process are still i mean it's just it's so

ingrained that if you are working at a low level of ethereum you're going to go look at the ip repository for to understand changes and we just don't have the resources to have every single change have you know a resource page and have write-ups and all of these things like it's you know we're we're still a lot smaller than you know that's a very good point did it really well and it's just a lot to ask for every single eip to have that many resources so that's why i feel like in the short to medium term we should you know keep things small that's it that's the best yeah that's a fair and compelling argument um you are right like you know w3c

and iatf they've got lots of resources when they want to like when there's a browser change for example um there's a spec for it and you know there's like 10 people who actually read that spec but it's you know listed on canius.com and 400 other web pages and people blog about it and like there's almost no one goes to the specs repo to learn about upcoming changes to the browser apis but you're totally right they it's because they have you know hundreds of people working on every single change not two and so maybe maybe maybe maybe the issue here is we don't have the funding or the resources to actually

achieve a goal and as a result we're trying to achieve an unachievable goal which just puts us in an even worse place if we didn't even bother trying i feel like it's gonna happen naturally because i mean if you just look at how eeps have changed over the last four four years or so you look at eep seven or whatever delegate call is and it's you know 50 lines and it's just there's just nothing there and now you know we're looking at some of these later ones like 3074 it's a you know really beefy eep and if that would have been proposed in 2015 it would have been just like oh the toxic this was a good idea let's just throw a couple lines down and then we'll just talk about it on irc or getter how to implement it and you know in five more years i'm

guessing that maybe every will have a 1559 style resource guide and all that stuff maybe it'll be eight or ten years i'm not sure but i think that'll happen naturally i'll think on what your argument here um it's very convincing the smaller resource pool okay uh so uh one last question i think i may have on this topic before we move on although i know this is not an encoded meeting and this is not like we are discussing the berlin upgrade here but it's a question to eip editors right now all the proposals of berlin

are on tesna and as far as i know there is only one eip out of four which is actually in last call and rest all are in review is it okay to ask the author to change it to the last call at this point of time i'd be fine as the first one um and if they don't want to i'm also okay with that okay um it might help if we like you said edit eip1 uh someone spent a priority everyone that just gets rid of that makes it more clear that the 14 days is a minimum not a hard requirement and then maybe in the future we can talk about removing before like the review end period and just have it implicit okay sounds good so i'm going to i think

that's for the push back here you'll get is that 14 days like people will be like oh we don't know if it's going to release in 14 days okay so i'm gonna bring it back on the agenda next to um in the next meeting as well um if we're moving on to the next topic are we done with this one since hudson has to leave in a few minutes um do you guys mind if i interject a quick discussion item that i forgot to put on the agenda yeah sure he's good um so for reasons that i don't fully understand

the burden of reviewing eips has increased it is now to the point where i am unable to keep up while also continuing to sleep every night and so i think starting probably this week stop reviewing erc's just because i need to drop something and it's either drop ercs drop sleep or drop eating and i've decided erc's they drew the short straw so either someone else needs to pick up reviewing erc's um or we just need to accept that we're going to go back into the state we used to be in where yeah if you are sitting waiting for a reviewer for months to years unless someone has a very novel solution i heard that people want to remove them

from the eip repository i've heard that too um i think while we find a solution if it goes back to where it was before where we're not like completely up to date on it and we have a lagging a lag behind that's not the worst thing in the world because that's kind of what has to happen but we should work towards recruiting more editors i still haven't cracked that code so i'll yeah still do one keep trying to get those things reviewed i feel like usually every week or two i you know try and carve out a few hours to really go through stuff it's just

generally there aren't things left over because micah reviews everything within about 30 minutes of it being posted good job promise to stop doing that i mean yeah if there's if there's open stuff i usually will get to them after you know a week or so so i don't think we're gonna get back to the place where it's months and months now reviews but i'm definitely a lot more open to removing ercs from the eip repository probably not something we can decide right now but i've known in the past i've been against it and i think that i don't know if it's just micah is really getting in my head and you know he's starting to control my thoughts but it's really on me over the last six months i've been

figured out i think i think it's fine that erc's are in the ap repair i haven't gotten it since yet yeah i mean i think the thing that just like really is like pushed me over the edge is that it they're so different than they're so different than core eeps and it's just so so weird to have the two like intermingled um so i would be very okay with having an erc repository i think the skill set for reviewing ercs is very different than eips i happened to have both just because of my history i came up through the deaf side and then

moved over to cordov sort of side later but i can definitely i definitely i know of people who would be very good at reviewing ercs and terribly reviewing eips and i also know people who are very good at reviewing eaps and i would not want them reviewing the rc's so should we recruit before separating or separate then recruit if we decide to do that theoretically not that we're making a decision today okay i would separate then recruit um just for the reason i just said like the skill set is so different that you're gonna want to look for different people

and it's much harder to recruit for the core eyepiece like the technical knowledge you need needs to be really deep that's true okay um we need to figure out how hard it would be to separate and like propose something before we decide i think i think the biggest issue is going to be that we're going to destroy every permalink to the github repo for ercs yeah that's a big one yeah we could hmm

well so in theory people should not be linking to the github repo they should be linking to eips ethereum.org i've been telling this for a while maybe we just say hey i told you to link the other place not my fault you linked the wrong one but i'm willing to be addicted to is we could just replace every erc with like we did i think uh the rc20 token was named differently and then we've got a placeholder there we could do that for every erc and keep that for three to five years and i don't think that that would really impose much of an issue because who's actually going through that list of files not not many people it's more the discussion links uh but we

could we wouldn't be deleting pr's or issues would we no no we actually don't have the ability to do that got it okay sounds good i gotta jump off i'll think about that part more thanks everyone thank you thank you [Music] uh elitas here did you want to go back to the bot uh yeah one last thing on that real quick uh i don't know is theoretically if we did want to do that does anyone have like a theoretical path to you know making that like who who needs to agree to that to make something like that happen the benevolent dictator of eips

so we're going to do it tomorrow then yeah i also don't know so the people who actually look at ercs are me and in theory other eip editors so very few and far between as you know and then there are the authors of those ercs themselves and then once the ercs get popular they're the people who are looking at them to implement those those are three people i have seen show up in the ips repo related to erc's one or three types of people mean i have been like looking at it recently just only for one thing if

there is a status review or they are trying to skip it right from draft to last call and that's my only comment for any erc that i have looked into so far maybe this is something that we could like you know bring it on the next call and uh like as an item itself like do we want to separate these vip and erc if people are open to discuss that sure just so people can chew on it the reason i want them separated and not just like say you know micro reviews core eips and someone else reviews erc's is that

github subscriptions i subscribe to the entire efps repository which i think an email notification for everything and right now that is about half erc's and it'd be nice if i could not subscribe to the erc half and i don't believe there's an easy way to do that um without splitting it out into a separate repository i think that's a general argument for a lot of issues that we have with you know governance is that a lot of people don't want to contribute because the noise is so loud but with them separated i think that there's just a lot less happening in terms of core eeps and so that may allow a larger number of people to actually review everything that comes

through because they feel comfortable doing that and then maybe people who want to look at ercs will feel comfortable because this is like an erc specific it's a little more friendly they don't have to deal with you know the core of the scary cordos yeah it's a very good point okay uh in the essence of time let's move on to like quickly go over a few other items and i will try to add that on the i mean not try i will definitely add that on the agenda next time to have a proper discussion on this topic separation of eip and erc and uh yeah coming back to alita's item i think we have discussed it briefly i want to just give

a chance to go ahead with the next items listed for today and if we have some time we'll go come back to item number one again to see if there are any problems to be reported so uh the next item on the agenda um is a progress on canonical source for eips i believe brent has something to uh talk about it yeah the meeting is way long so i just want to mention that we've forked the repository and i'm working with one of our part-time engineers to figure out the bot system that makes eips.etherium.org so we can make a mirror of that site once we've got that running we're going to start making changes the changes we're proposing and i'm proposing those in the dark so

just want to let everyone know i'm pushing in that direction that's the progress we've made so that's that's all i need to mention today we'll talk about it later did you have a specific question because you were mentioning something earlier well i just need to get more educated about how the robot system and the eip or the eip github repository works what robots are involved and but but i can do that on my own time with my part-time engineer and then do that so we don't have to okay i was just going to say that yeah it is mostly jekyll so jekyll will come basically compile the eips into like static website files and then yeah yeah i've got my part-time engineer and i are

looking into that we're figuring that jekyll stuff out so so we'll get there just take it a bit so but thanks for the support yeah we're yeah if anyone has any helper uh but anyway yeah we're working on it so thanks thank you ben for that so coming back to item number one uh which was on the progress on eip github repo now that alita have joined arita if you have anything to update on that and we know that this is already in a pull request on eip github for editors to review do you want to add anything on that

um no not really i think um that's that pretty much covers it it's in review um yeah can you um ping me once you're i notice you're making a bunch of changes and so i kind of stopped checking back can you just mention me on that once you're to a point where you're you think you're done with all your next round changes and i can review it again yeah so after that that um is one thing that i i added you um did you want tests i wasn't really clear i mean i always want tests but um i also have been an engineer long enough to

know how much of a time sync that can be and so the question is is is it worth the time and i don't have a good answer to that one in your opinion how easy is it to test github actions is one of those things where you have to spend like two weeks just figuring out how to test a github action like in automated fashion or something like you don't know how to do that so i can build like a um like a custom system that'll just do it like like a mock basically which is what jess is for anyway um and what that means is basically like just creating like some basic not necessarily perfect uh reproduction of a pr just to test

certain behaviors um the biggest thing is like there are a lot of edge cases to do um so like like i mean i i there there are bugs with the current bot like a lot of them i think so like yep like it only runs half the time yeah well wait well but anyway like th there are a lot of things that are wrong with it um which admittedly um you know writing tests would be a really great opportunity to then like test and fix those edge cases but also um the bot seems like a perfect um candidate for tests like to require

tests because no one's going to notice when a test when something's going wrong but anyways um like i would say it will take me about one to two weeks to get um a solid baseline of tests going um so if you all are okay with that then like i think it's fine and i can do it so my feelings that that one two weeks aligned with my where my gut was just just looking over you're kind of looking over your shoulder um uh that's of the order magnitude this is what kind of this is almost a question of should you test your test sweep

because the the bot is effectively just kind of a test runner that is supposed an automated ci process and spending one to two weeks yeah i mean you can definitely test your tests it's just a question of is it worth the time like would we would that time be better spent making the bot actually do better like making it you know do more things like there's a we have a list of things we'd rather have the bot do like if you have one or two weeks of engineering time we can either sync it on making sure the the bot is robust or we can sync it on making the bot more feature-rich and i'm on the fence that's twitching more valuable i would like to see you know just a

couple you know really basic tests of the eip you know checking functionality just to make sure that okay for these simple cases this makes sense you know it did they change the status to review if so then that needs an ip editor i don't know what the control flow exactly is but just you know a handful of tests you know i don't expect every edge case to be tested but just a few sanity checks i think would be valuable and then having the structure for you know writing other tasks in the future would be nice okay that um that makes sense as a first as a first go um and then you know obviously

like i'm happy to continue work on it as well if you all wanted to keep me on with that um but like in regards to like building out test versus um well first off so for this pr it would make sense to build out the infrastructure for tests not necessarily tests themselves and i could get that done in like um i mean pretty quickly but but anyways um [Music] like i think that the the bot itself really needs like very comprehensive tests just because like um it's going to be really hard to build out things when um like

the bot needs to be on point otherwise it's kind of like gonna cause problems right because like if we're just like auto merging things because of some bug then that's gonna mess up the repo so i think that we it would be better to be sure than to have problems with this sort of thing yeah that's a good point i forgot that this particular bot um a failure in the bot results in bad things happening like it's uh it's not just like oh that didn't help us human can step in this is oh the bot actually made things worse that kind of that pushes me more towards

the yes we should test more stuff and then also um when it comes to like the actual code itself like it for some reason it's pretty i mean i think it's because it was reporting from python or something like the logic was pretty tangled so there is still some work to do as well like to make it expandable because right now you can expand it but like it's just going to cause problems but anyway sure getting the infrastructure up in a place that uh the rest of us can iterate on i think is a very valuable first step like so you're talking about creating a a mirror of eip repository on a server

right and that's exactly what we're building so yeah we could do all that stuff on this uh repository that i'm working on we're going to be tweaking the getting the jekyll script and everything running on a server and that that would be it seems like to me that'd be a perfect place for elita to run or tests and develop testing and make sure everything runs on this um a snap or fork of the eip repository then once and we can keep updating that fork and run the scripts and develop tests and stuff like that anyway yeah i'd like to get our part-time engineer involved and help with some of that we can do that so um we don't need a server or anything for these tests um they are straightforward and well-defined for github actions so it can be done in a single repo

um so yeah it wouldn't really be pertinent but is it going to be taking action on live data and stuff like that um i'm not totally sure what that means but with the current behavior we don't need any um we didn't it doesn't need anything else no okay yeah i think i'm convinced i'm a flight client just getting you can test infrastructure up at least and then um a few a few standard checks on the most egregious things like the things that we definitely want to make sure get blocked such as is one of the authors the pull request

author or did they approve it like that's kind of the the one thing that it does good and is it not in the wrong status like if we can get those two things tested at least on the surface and that would go a long way i think and satisfy me okay that's achievable i'll let you know when it's done thank you do we want to so the other option is uh no thank mine i guess we can't merge this until we're ready to put it live right um i mean you can always just disable the the action so you can merge it um and then disable

it is it possible to manually run the action well it's disabled like that um no because it's triggered based off the pull request itself um some more manual triggers like we started out as a manual trigger because i i'm not i'm not sure about how to do that so if that's possible if there's a manual trigger and i want to say there is i think i saw a repo that had a manual trigger github action if there's a manual trigger then we could merge it and then use it manually when the current merge bot fails which is pretty often

because when it fails i'm currently closing the eip and reopening it if instead i could just go and say oh i'll try elita's bot and click the button there i'm already sitting there watching it and so if it does something wrong i'll be there to catch it and fix it and so that might be a nice way to get kind of test and production so to speak theoretically there's definitely ways where you can tag a bot and give it a command i know boris has a lot of functionality like that where you can tag boards and say okay once you know the other people on this approve go ahead and merge it i don't know how hard it is to implement like a really simple um that like some functionality really simply but it can't be done

um kind of because we're short on time i wanted to hop on one other thing um did you all want me to go out and build that uh like the bot and do a separate repo um and i can just do it like i can set it up and then um like hudson or whoever has permissions can like i can just give over control or something like that um i'm on the fence like clients have convinced me um the plus side of having it in the eips repo is that it's right there and the same people who have right access to the aps repo would have right access to the bot so when we the the people who have write access to that repo

notice it doing something wrong or we want to make a quick patch we know we have permissions and so if we add new editors those editors will automatically get the correct access rights um having a separate repo though is just from like a modularity and keeping separation of concerns that doesn't make more sense in that regard i'm on the fence if other people have really strong problems this is definitely not a hill i want to die on on either side i feel pretty strong that it should be in its own repo i think it's you know several thousand lines of code and i don't really want to mix a bunch of pr's between the two things i agree with light client in addition to

that um we can it'll make it a lot easier to do um like in um pli for the bot itself yeah okay i'm convinced the uh having using my own argument against me that was that was smart i just argued before uh earlier that we should separate ercs and eips so people could subscribe more specifically and having yeah uh bought prs go to the same place that er eip p hours ago would not help with that so yeah let's get it out separate repo and then did you want me to do it or um were you waiting for um someone else i forget i know who it

was but i'm forgetting james is the one who has the ability to create a new repo in the ethereum organization which ideally is where this would live in the meantime if you just want to put it in one of your own repos it's pretty trivial to move it over once we actually do get a more permanent location just have to update a couple links so i would say if you want to split it out into a separate repo just in your under your username and github we can use that for now and then once james can create an ethereum slash eip bot repo then we can move it there that'd be what i propose okay sounds good

thank you alita um my car and light friend so uh with this discussion it seems like uh we are going to see some more actions uh and we would want to keep this in the next meeting item as well so uh we'll wait for your uh progress there um i think we are over time uh uh i wanted to quickly cover on the eip editors onboarding thing we just have you know uh try to answer most of the questions on the eip discord itself but if you could not get answer like i have created this new role in the ech discord as eip editors aspirants and

if you are not there you want to be on part of there if you have any further questions please reach out to us like you can dm to any of the members of of the ethereum cathedral or post your question directly in the general section of the ecstatic call um uh that was the last item on the agenda um thank you everyone for joining us today see you all in next two weeks on march 24th thank you thanks future everyone thank you