EIPIP Meeting 52

Transcript

Welcome to EIP meeting 52. I have shared agenda in chat. Uh the first item listed here is GitHub discussion for discussion 2. I have added a link which I collected from the EIP GitHub issue. Um it is a proposal to initiate EIP discussion to thread at GitHub discussions. Uh as you can see Michael already pointed out the potential problem with GitHub discussions uh that they are not distributed and cannot be reconstituted.

Um however uh I I feel like the in earlier meetings we decided to move ahead with Ethereum magician one of the issue that that was highlighted was uh the limited editing window but I'm happy to share that this issue is now resolved and uh I'm just trying to understand now like uh are we good with FM continued as discussion to place and um we don't uh want to look into other options Or are there any other issues that needs to be taken care of before we start increasing awareness of FEM as a central place for discussion to link?

I don't believe there's anything else blocking us. That was the the big blocker that I remember. Um I have already basically told everybody you have to go create an theory magician thread for discussion links. Like anyone who creates an issue on our GitHub, if it's not related to the IP process itself, I tell them to go to your magicians and I close the issue. Right. I Yeah, please go ahead, Sam. No, I was just going to say there's there's nothing stopping me from recommending Ethereum magicians now that the edit window is fixed, right? I know uh we have uh changed some text on the GitHub bot to help people understand that if this is related to

EIP discussion, please stop it or close it and create a thread. But we were trying to stop ourselves from strongly recommending it. But it seems like with this issue being solved, we can start doing that. Thank you for that. Maybe I can go ahead and add a comment at the end and then we can close that issue. Number two is removing spam issues and comments. Uh this is uh collected from the eat R&D discord. We all know that uh we have the EIP GitHub repository is being spammed a lot. people come and write something that has already been discussed in the

past that this is a concern that we don't want to provide an opportunity to scammers to just create something and be a part of Ethereum repository. So we did talk to EF DevOps team and it seems like uh with editors EIP editors having admin issues now they are in a position to close the spam issues. Um it just that we might need to update the list of EIP editors so all EIP editors may be able to handle this thing. Does this sound like a reasonable solution to the problem or anything else can be done?

I I don't think that's necessary. I think that I I just didn't know where the delete button was. I I've been using GitHub for forever and I never even saw that button. Now that I know where it's at, I can delete issues and so I don't think it's a problem anymore. Um I think having me and like clients are both admins. Um, generally I am in the camp that from a security standpoint I'm in the camp of people that believes that you should limit who has access. And so if we are going to add people, um, I would recommend removing some people as well. Um, I'm okay with that. If someone wants to remove me and add someone else, I'd be totally happy.

Um, but I don't think we should just add everybody. Like I think it's an unnecessary distribution of very powerful permissions. Okay, we just keep the list short basically. I am very happy to not be an admin. Damn it. All right. So I I think um we can probably check with that. It seems that list is pretty old and it has access to the like emer editors as well. Uh so we will try to get the list shorter with whoever has have admin access as of now for that repository should be the um owner of it and yeah that way we hope to

spam issue get addressed. All right moving on uh number three is discuss issue used to get subm modules. I think this is also collected from the EIP GitHub issue section. And also the user the GitHub user Panda PIP1 uh he left a comment to the agenda item uh suggested suggesting that he's looking for some uh decision on this topic.

I have added the link in the agenda. So it says that currently Travis CI validates all files uh including git subm modules which the EIP author has no control over fixing. The git modules file will be edited every time someone added a git subm module. The bot should not fail when this file is changed. I'm wondering what is general thought. I see some of the editors have already left a comment but if there is any decision or discussion needed on this topic. I'll just reiterate my my position. Um I'm not a fan of Git sub modules in the EIP repository. Um they add a lot of complexity and it introduces external links. Um and so it's functionally the same as just external linking which

means it can 404 it can go away. All the problems we have with external links would also also have get subm modules. On top of that, um they just it adds a lot of complexity to the repo. Like when you clone, you have to do a bunch more steps in order to get subm modules. Um not a huge deal, I think, in our case because most people probably wouldn't need subm modules for day-to-day tasks. Um but we would have to make um CI accept them and deal with them, etc. So I'm generally against subm modules.

Yeah, I I'd agree. I think um I think they're slightly better than just arbitrary external links, but they definitely suffer from some of the same problems. Um and you know, I'm okay with like a soft stance against them for now and then, you know, if it comes up down the road or or comes back up as another like reoccurring issue, then we can discuss it again later. All right. Um so I see Micah has already commented here on this issue. U maybe uh we can go ahead and add as a general consensus for this meeting uh that EIP editors are not generally in favor of this uh so we can probably close this

issue for now but if then something else comes up we need to bring it back maybe we can create another issue and start discussing it at that point. I love EIP meetings where we barely meet quorum because it makes it so easy to come to decisions. What is the quorum? Two. Oh okay. Basically, the quorum is more than just Micah being a dictator. You know, I'm probably not the best person to sit opposite you on that. Oh, well, that's why I have been trying to kind of readjust that time so it suits uh rest of the EIP editors. Like we have five on board, I believe, right now. One, two, three, four, five. Yes.

And um I was trying to reach all of the EIP editors individually so we can get a time um good time for everyone to be on the call. Uh we'll discuss that that is there on the agenda maybe later today. Let's uh let's finish up with whatever is here first. Um number four is mention number of EIP drafts uh that were submitted but not merged in the EIP insight. So this is again a comment by the same user and uh he is requesting that in the report that we published EIP inside we should also add pull request those are not merged.

Generally how I add details over there that whatever pull request is merged is reflected in what category it is what status it is sorry I wasn't uh adding the EIP category and type but it's a good suggestion that we probably add uh type so we will be able to keep track of how many of what core networking uh and other EIPs are being added and being finalized but I'm I'm still into minds that's why I wanted to bring it here like do we find a good reason to include data for the pull requests which are not merged as long as it's not too ownorous to

collect I don't see it as a bad thing I mean it's kind of a an indicator of how much work EIP editors are sort of doing well yeah it's like you can kind of compare the ratio of things that were merged versus not merged and then be like you guys are doing you know a terrible job as the IP editors or maybe we need more people. Yeah, please go ahead. Yeah, I tend to agree that if this is an easy thing to get metrics on and someone has requested it then I see no downside to providing it. Um it might give insight into how overwhelmed uh we are or maybe it will give people data to say wait you guys aren't actually

overwhelmed. You keep up with everything. Clearly you can handle more work. I don't know. But I'm not opposed to it being added if it's easy. If it's really hard to get that data, then I'm more opposed to it just because I don't want to I don't think that's like a super high priority item that we should, you know, devote significant effort on. Right. I don't think it should be a challenge. uh it's just that the reason for not including them was like not to clutter the report too much because uh if if we want to look into the pull requests there are plenty of pull requests like a a big number is there and we wanted to filter out data probably I have to think of some better way of representing this metrics as well but I agree to the point that it is a

good reflection of how much work is there with EIP editing and this might probably help us get more people if we see that uh the present EIP editors are overwhelmed with the job that is assigned here. All right. Um I will try to add the data for open pull request for new proposals and proposals which are added to be moved to the final status and we'll try to add this data at the end of the month. Okay. Uh moving on number five I item number five is core EIP in an executable spec world. I know um this proposal was

proposed by TBU and was also discussed in the all code meeting. Now that we already have the discussion to link for this proposal I don't know this is a formal EIP or not. Uh discussion to link is also available at fellowship of Ethereum magician and I have added the link to the agenda for people to refer to. I just wanted to add it to the EIPAIP meeting because I know this is about process and I'm wondering if there is any other thought that people would like to discuss. I'm still holding out hope um though I'm losing I'm pretty sure I'm losing the fight. Illy not hope that with the

executable spec we can just move core EIPs out of the EIP process and into some new process that is more uh fitting for what core devs need. But I'm pretty sure I'm going to lose that. So why why do you say you're going to lose that? It's the impression I got. Everybody seems to really want to not move core EIPs out of the EIP process or people. Yeah, people really want to retain the process and they seem to want to keep it as close to the current process as possible, which I also am not a fan of.

Um, I mean, I think there are some some reasonable arguments for that, such as continuity and, you know, mental effort for the core devs, things like that. Um, I personally think long term we would be better off if the core devs had a a process of their own that wasn't also infected with ERC's and you knowformational and everything else. Um, and also that was you know once we have spec a process that integrates with that better than the IP process would. Um, yeah, it's just the the impression I'm getting currently is that there's a number of people who don't want to leave EIPs behind.

Well, I mean, hopefully we can convince people that there's a better process. Um, kind of hoping that that's what we'll do with Shanghai when we get there. But uh yeah, it may help u if you're not busy, Sim, it may help if you can write a proposal similar to the one Tim wrote, just like in a similar vein, but you know, proposing some alternative solution to uh core change control.

Sure. So, I was actually helping Tim quite a bit with his um but I guess there's still some parts that Yeah, I'll go through this and I'll I'll write up like an alternative one. So, cool. Yeah, I think the idea of having this pack and def that we discussed in earlier meetings, it was nice nice to have. it would actually differentiate core EIP process with the rest of the EIP processes. Uh even if we continue the normal standardization process as the same, it's like what we want to keep it in the in the file.

Yeah, like like I said, my my preference would be we don't keep any anything core EIP in the IP process. Once the executable spec is out, we come up with a new process that is separate. And I feel like like I feel like we can come up with something better given a green field that rather than trying to kind of come up with something that looks kind of like EAPs and fits kind of into the EIP's repo, but maybe it just has some rules changed. Um, but I I will admit that I have not thought enough to be able to actually document what that might look like. And so I'm hoping maybe Sam has something in his head that could be written down that achieves that.

So what were the problems you had with Tim's uh specification or or or proposal? I guess proposal um like so the in the high level proposal section he says use core EIP for both EL and CL changes and my understanding is that he basically wants to keep EIP as is with the exception of the specification section change section you still have the header the metadata etc still in the EIP's repo it still be go through the same editorial process etc um I I feel like we can do better and I feel like this is a good opportunity to extract core EIPs out so they can not live next

to ERC's and other things. Um and I feel like tighter integration with the um executable spec change control process would be valuable rather than like okay here's the then we point at like a pull request or something but then that pull request you know might change over time or you know it may be handed off or you know someone moves a repository like that it feels like there's a disconnect there whereas if it was more tightly coupled I feel like we could do better. Yeah. Okay. I think that's that's the big difference I see between what I want and what Tim wrote um as well is where I want the EIP like English text to be part of the execution specs repository.

So uh yeah I can I can write that up. I mean I think there might be value in retaining some things from the IP process that we found were valuable and useful. Um well like the motivation section is like really important. Uh yeah, so like keep keep something like the motivation section. Um you know, the rationale did serve a purpose and I think it was valuable. Um like I think that's a good section to have. Um but like maybe we don't need to have the abstract. Like lots of people complain about having the abstract and a description and a title and maybe we just don't need those three. Um you know, we just use numbers and that's it.

Like we don't we don't need title at all. I don't know. Yeah, I I'll see what I can do. I'm probably going to keep the the template from the EIP repository mostly intact. Um just cuz I think there's some continuity there. But yeah, let's see see what we can cut. That one bugs me because it's totally redundant. Which one? the in the header there's a field for the date that the IP was created which is information that is automatically tracked by like three different systems already. Don't need to manually type it

in. It just it bugs me because it serves no useful purpose. Well, and what does created actually mean? Is created the first time the text was written or is it the the date it was merged in? Like Right. Exactly. It's an ambiguous field that doesn't add value and is redundant with lots of other things. So if we're going to at least let's remove that if we move to another place and keep everything else at least I'll feel good like something changed. But about that particular but about that particular field I feel like that is the only uh way to like give a high level information when someone is looking at EIP.org org right that can provide a reference of like how long back this EIP was created obviously that feel is

ambiguous I do agree because the proposal is created like four five months back and then it's merged so I don't know if they would want to consider the date of merge as the date of creation of that proposal because that is the first day when that is listed on eipethereum.org or or the day when it was actually documented. I would like if if we wanted to keep things on Ethereum.org um APthereum.org that I would like that that field just be filled in automatically um when the draft is merged uh the draft the file creation date basically.

Um and then maybe once it goes final we change that to the final date because really an EIP is in draft is not an EIP. It's not a standard yet. It's not there until it gets final. And so the final date is the one that I think matters the most once you get there. But again like my big contention with it is that we could automatically generate that and we don't. We have users type it in and that bugs me. I think it's a very good suggestion like uh the date for the EIP uh the final date when that proposal is actually merged. Let's consider that as a date of EIP. Maybe this is something that might need some more discussion, some more feedback from other EIP editors. But that's a I mean I consider it as a good

uh piece of information for people and we can probably have some standardization over there. But if we have to consider that I believe it would be a bot work right someone has to add some fields over there. I mean there's going to be a lot of bot work to move the core EIPs over to this repository. So yeah, in comparison to that, this is a small change, but but that's a good point.

Yeah. So like like I think there's going to be some advantages because like the bot code can actually live right inside the execution specs repository. We already have tooling in there that does linting and so we can just extend that for the EIPs. Um but yeah, like it's going to be a lot of bot work. All right, let me uh let me bring it uh to the agenda in the next meeting and let's see what other people think about it because I'm also confused about this state. Um I'm talking personally from my experience because when I add EIP as like you know draft and the final in EIP's inside document that is based on the date when in in the month which it

was merged but that definitely not matches with the date that is reflecting on the EIP's on um like EIP's website. So if we have this thing in sync, it will make more sense. That's a good point. Thank you, Mah. You gave us another point for discussion in the next meeting. All right. Okay. Um, moving on. Um, I I think we have a good discussion on the core EIP part. We hope to see something coming up from Sam Wilson maybe in the upcoming meeting or the ACD meeting. I don't know Sam when

you are ready with that but it would be good to have couple of proposals on the table to see what is the best suited and what people want. Agreed. Okay. Let's move on to item number six. EIP bot issues and EIPV issues. I'm aware that some work is is started by the EC engineering team though we we are still in need of more people. In the last EC meeting we also um shared the information that we are looking for more Ruby dev though we haven't received any application from from the community. So people if you are listening we are still looking for more people to look into the bot issues and EAPV issues plus we are

also looking for a Ruby dev. If you are interested to work on the EIP side or help out with the Ethereum um GitHub, please reach out to us. Um you can find us on the EC caters GitHub. Sorry, ECH CATers discord channel. The next one is EIP's insight. So uh the report is updated till till date. So far in March um we have one EIP which has moved to the final status that is EIP 4626 tokenized vault standard and uh the repository has received seven new proposals as draft five core proposals

and two ERC proposals. I have made this distinction for draft and I will be making this distinction for the final EIP as well. There are 13 EIPs which are moved to stagnant and one EIP that is EIP 3651 warm coinbase is resurrected from stagnant to review and is also being considered for inclusion for the Shanghai upgrade. Uh we did mention in earlier meeting about the significant change to EIP1 which is about limiting the links to external resources. However, there is an open pull request that is submitted to further edit language on uh on the usage of external resources. I wonder if there

is any any resolution or any uh discussion that people would like to have in this meeting. I'm sharing the link here. What do people think that should there be any changes or is it fine? Sorry, I could not catch it. Micah, I was saying one second. I'm opening the link. All right. All right. Yeah, just have shared the link. Yeah. This one um I think Sam's comment or no Matt's comment, most recent one I generally agree with.

Um, yeah, I can go either way. Like Sam, if you have a strong opinion, I'm probably willing to defer. Oh, I I I don't think we should change the text. I think what's there is good. So, you you prefer the the short oneliner? Yep. Over the slightly longer twoliner. Yes exactly. Okay. Yeah, I can I can get on board with that. I think Matt was also favorable to the shorter turser version. All right. Uh maybe if one of the AP editors make comment and then we will be

in a position to close the issue. So I mean that when the issue is addressed, we can probably close the issue. Okay, I'll make a comment on it. Okay, and I think that's all from the EIP insight. Number eight is EIP editor apprenticeship meeting. Um we did have this meeting yesterday and we did try to catch up with the some of the open poll requests. Uh the recording is available now and the next meeting is planned two

weeks from yesterday. Second last item number nine is EIP IP meeting time and survey. So um we had this survey to collect information from the EIP editor. So far we have five EIP editors on board and um uh this survey was for the collection of uh time which would work the best for most of the editors. So we can have most of the editors on the meeting and uh if there is any preference in the name change for this meeting. It looks like uh 1400 and 1430 UTC is on a tie. people are mostly in favor of EIPIP meeting and

they do they are not looking for any change. So now that today we had this meeting at 1500 um I'm open to like a revise calendar for uh next meeting onward but again there is a tie 14 or 14:30 what would be the preferred from whoever are present today earlier is always better for me because I'm in the east and uh later is always better for me because I have a terrible sleep schedule. So, and you're in the West, right?

Yes, I have a terrible sleep schedule, but uh that makes earlier better for me because of that. Yeah, I mean I' I'd be okay with like 1:00 a.m. Eastern if that's easier for you, but I'm pretty sure that would uh be terrible for the other EIP editors. What is 1 a.m. Eastern? I think that's like uh around noon for me. I'd be okay with that. It's 5 am UTC. But uh yeah, anyways, I think uh you know 1400 UTC 5 a.m.

5 a.m. UTC. So Oh. Oh, you're saying like 5 a.m. Eastern time. Uh no. 5 a.m. UTC. 5 a.m. UTC works for works for us. We have quorum done. Um yeah, I don't know. I'm also okay not really moving it. I I can usually make the the current time. So whatever works for everybody else. I think 1400 is generally preferred because we have code meeting at 1400. We have CL meeting at 1400 and if we keep this meeting even at 1400 it will be like easier for people to remember. We did keep it for 1500 because it was earlier required now but now there there is an opportunity with new people in

here. I think let's let's give it a try for 1400 and uh see how it works. So far this looks like this has been like preferred by most of the editors. I hope you will still be there Sam. Yeah. Yeah. Yeah. Should be okay. Okay. Um yeah. So uh the next meeting will be on April 6th at 1400 UTC. The last item here for today is review action items from previous meetings.

Let me quickly open it. Uh EIP editors will complete survey to finalize time and date for future meeting. We just decided on 1400 UTC. That seems like most of the EIP editors want to have. Uh discuss potential alternate names for future EIPAP meeting. It is going to be EIPAIP meetings. Puja will add a list of exceptional cases that may allow a data non-normative changes to final EIP to hack MMB file as reference to EIP as reference for EIP editors. I keep updating the EIP editors uh apprentice file uh that is there with FAQ for new people who wants to get on board uh with EIP editing task. I don't know I haven't

added the link here but maybe I can share it here in the group. So if there is any suggestion from any of the editors here that can be added. I'm trying to add things here which is not for the EIP1 but still it is useful for any anyone who wants to contribute as a reviewer. So yes uh uh that is added there. And uh the last one is uh Puja will contact FVM reability to edit post. I think this issue is resolved now. So we should be good with uh promoting FM as

the central forum for discussion tool link for any discussion related to um new proposal or EIP draft. The other two items are puja we follow with EIP GitHub admins to update setting to allow admin to delete spam issues. That is done. And again FPM limited editing window that is also done. So I think we are all good with uh the items listed here. Anything else anyone would like to bring up for today's discussion?

I'm good. Thank you. Cool. So it looks like we are making progress and uh in the past I have seen that people have started adding issues to EIP GitHub repositories for things that they would like EIP editors to be looking into. So slowly we are making progress and we are making good use of the EIP GitHub issues section and we hope to see that eventually that the discussion tool link will be removed completely maybe not now then five to six months down the line and yeah we'll we'll be uh having one central repository where everyone can go share feedbacks on the proposals which are upcoming or on the existing proposals.

All right, I think we are good for Yeah, please go ahead, Micah. I have noticed there's a a few people um who have been regularly uh commenting, participating um trying to help out a little bit in the EIPs and SkitHub. Um have those people been invited to this meeting so they can kind of escalate their level of participation? Actually, I tried. I did left a comment for one of the uh participant uh but he said that he unfortunately would not be attending the meeting. It's just that he's just trying to add suggestions for a topic to be discussed but I'll be getting in touch with those people maybe if when if or when they are ready to be a part of it happy to invite them.

Okay. And there was this again um an issue which suggests that people are looking for some ERC meetup to discuss this kind of thing like what's going on with the ERC and help out new authors to document ERC. Uh in response to that issue also have left a comment that if people have questions related to even ERC they are welcome to join the EIPIP meeting. So we can address all these issues or they are free to comment to agenda to be added in the meeting or just create an issue at Ethereum EIP GitHub. We can also collect information from there. We are trying to open all channels for new authors and

people who wants to contribute as a reviewer. So yeah, we hope to see more participation in future. Well, thank you everyone for joining us today. Uh the next meeting is uh on April 6th at 1400 UTC. Have a good one everyone. Yep. Thanks Puja.