EIP Editing Office Hour #76 (EIP Only)

Transcript

Hello Vendra. >> Hi Puja. How are you >> doing? Very well. Thank you. uh Vendra we won't be able to stream this meeting uh but it will be recorded and uploaded right after the meeting and uh I think >> yeah it will also be having summaries all by bot and things like that we are working on automation of you know all protocol calls so this is just an effort in that direction would you want to quickly check this >> uh sharing permission if it is working well for you.

>> Yeah, that's what I'm checking. >> Okay, I've shared the agenda in chat here. [Music] Looks like it's working well and I also

see one of the first PR is merged. Anyway, um so Gachendra, I know we have a lot of open PRs, but it wasn't very clear to me like how do we engage other PRs mostly in draft category they are there so they are new but because this is for core EIP I just have tried to put together a small list here which is miscellaneous and some draft. So if we are done with this we can perhaps take a look into the review from EIP board to address some of the issues. If you are good maybe we can go ahead and get started with the meeting.

>> Yep. Let's go. >> All right. Welcome to EIP editing office hour. This is meeting number 76 and is added on Ethereum PM repo with issue number 1775. On agenda, we have added only PRs which are related to EIPs uh like from the EIP GitHub repository. We do have some proposals to review under miscellaneous and a draft category and once we are done with that we can go ahead and take a look at the EIP board if time permits.

uh people who have joined here on the call, if you are here for any particular EIP related PR, please drop the link in the chat and we can perhaps take a look. Uh please be mindful in this meeting, we are only going to cover uh EIP related PRs. We won't be able to review ERC's unfortunately. However, you can drop uh your PRs related to um ERC for the next meeting which is on next Tuesday and uh the issue number is 1776. So yeah, thank you for joining and Gajender thank you for joining us here.

We can perhaps go ahead and get started with the first PR which is in the miscellaneous status not status but under category of miscellaneous here for review. >> Yep. Thanks Puja. Uh yeah, let's get started. So I looked into both of these PRs and uh so these PRs are regarding uh some technical changes and uh over here it has already responded. So and I also added my command because this is my EIP as well. So I'm co-authing it. So basically this is technical stuff and uh not under the perview of EIP editing. Similarly,

this other EIP whose author uh I am again it talks about some technical changes and I have basically responded uh that sort of this sort of is not correct. uh so we'll wait for author to we will wait for uh the PR author to respond but as such again this is not under the perview of EIP editing uh the CIP which was this PR which was sort of blocked getting blocked from merging it uh I basically restarted uh all the CI actions and uh it sort of

merged uh on the draft. Uh we're coming to the draft the new EIPs. Uh this EIP I was able to approve. Uh so it is now merged and is a draft EIP. Uh let's look into the PR10554. Uh I also looked into this and uh basically have raised some pointers which author can review and sort of address them and when they do we'll again come back and uh review this.

Going to the next PR for new EIP. So I think uh uh Andrew already provided uh an EIP number which author has not yet updated. So we'll wait for author to do the updates and get the CI passing and then we can basically do the do some review although I did some review and again uh there is uh there is quite a lot uh of code that has been bundled it's a Python code and uh so Pujab baby we should again put this

issue into EIP IP meeting that uh what is the best way to handle reference implementations s because obviously we don't want them to uh we don't want them in our EIP repo because it will make it unnecessarily bulky and obviously we don't want any active code I mean we don't want we want pseudo code as code reference but we don't want any uh active reference code uh that uh that is in our uh EIP repo because we don't want to sort of distribute it. We don't want to become an agent to distribute this code uh without uh uh through our EIP repo.

So this is something uh we should basically discuss in EIP IP. >> Yeah. And I have also referred to the author that maybe if they can refer to the code in a very high level pseudo code that is actually better when you are trying to explain concepts which is what EIP process is all about. >> That's right. That's nice. Um actually we kind of briefly discussed this in the last EIP meeting. I believe um you had pointed out another similar PR where the author was trying to make fellowship of Ethereum magician as a placeholder for reference implementation.

It seems Sam disagrees to the idea because again fellowship of Ethereum magician is a is something that can be open for forever and it will keep on changing. So um he disagrees to have that link being added as reference implementation but I'm happy to put uh PR number 10557 as you mentioned again in the next EIPAIP meeting maybe we can come up with some different solution to have reference implementation added. Yeah. And I think there is one particular ERC that I'm not sure whether it got merged or not but again it was sort of raised by Josh Rudolfph uh where they wanted to link a reference

implementation again uh which is how I was suggesting them that okay you know refer them in your Ethereum magicians link but that magicians link also doesn't work because bot sort of flags it anywhere except discussions too. So in that sense yes we need to sort of find a proper solution for it uh how to best add the code reference if we can for this particular I think we can discuss it further in EIP IP but uh if we can for example just allow GitHub code references with a fixed uh commit number uh any GitHub code reference with a fixed commit number in the reference

implementation section I that would be the best way to deal with it. But I guess we can talk about in about it in EIP IP meeting. >> Yeah, that sounds good. Yes, the idea of not adding um fellowship of Ethereum magician in the body of the EIP. We do have it in the preamble but that's fine but not in the part of body. >> Right. Moving to the Okay, this was covered.

Moving to the next uh new EIP proposal. So I have I assign the EIP number and seems like author has author is sort of fixing uh the PR and uh when the author will be done and it will be all green then I will give it a review. Sounds good. >> All right. So, uh, what do we want to do now with review from the EIP board?

>> Yes, perhaps we can take a look at the EIP board. I understand that we have a lot of open PRs, but most of the PRs there are in either typo fixing category. I understand where until we get response from the author, it doesn't make sense to be added in editor's review list. So, I left it as is. We can perhaps look into yeah some of the old PRs from here. Now would you like to sort of uh take on the control and for the viewing section because I I don't understand where to go.

Uh should I filter something over here? >> Um so uh there is uh this if you scroll up a little bit there would be uh download report. So you can just perhaps download report and that will give us a complete list of all proposals which are added there. >> So is the report visible as well? >> Uh it is not um but it is in the same sequence as you can see it here in the serial number mentioned.

So you can click the view PR from here with the same serial number. >> Okay. So the 9354 this was a new PR I think should >> Yeah, it's the first one. Yes. I believe this is long pending. Bulma added something but we never heared back from the author the proposer >> right but if this isn't passing and

author is not addressing it I mean >> it is sort of not on it is not on our on users to sort of push it forward >> right yeah so that is that is the reason why I was like mentioning this before like there are so many PRs but those PRs are not pending on editors they are pending on authors or the proposals so a lot of proposals are just there for review for example the next one 9395 I believe it is waiting on some conflict resolution that can only be done by the EIP author >> oh this is I think

he's sort Now we can >> now we can even add uh I guess um 7569 new I think Alex is also co-author now right? Yes. I mean he if he proposes a PR will sort of add him a co-author and accept him as a leader. >> Oh but I see him as a co-author right now.

So >> not on all the PRs. >> So for example this particular Mhm. Yep. >> So now what is the how do we move forward >> because we know is not going to be available for some time. >> Yeah, I think we should just bring it uh to the attention of Alex, I guess.

>> Okay. at at least where we know that you know who's the person in charge for these PRs. >> Yeah. Right. Right. That is a good idea. >> Uh I believe Rohan has a question comment. Rohan, you want to add something? >> Yeah. Um this is just a general comment on the EIP ERC process like like submitting one. Um I think like I I just heard you mention like you know how the onus isn't on you guys as the reviewers like if like you know there's certain format issues and things like that which I totally agree on right cuz you're not the ones writing the ERC I think that totally makes sense but there is no documentation

um on like the process or even like the format or anything like we had we struggled and like you know we we worked with Davidid who's like you know like heading all the AI stuff at Ethereum and we worked with him. He he said like, you know, this is great like, you know, submitted and then it took us like over a week just to get information on, you know, like like what the correct like formatting was, you know, how like like the different tests were structured. There's like a bunch of other like small issues that weren't really described anywhere. And I guess I'm just wondering like is there a reason there's no documentation that exists on how to create these proposals or is it just that you know like everyone's just expected to figure it out on their own because I think I think it would just be

much more efficient you know if there's like some place on the magician's side that said like you know this is how you should be um submitting your PRs because ERC1 describes how the proposal like should be made and like like what kinds of things should be in it but the PR is like where most people get stuck and there isn't really documentation there. >> Yeah. I mean the reason for that would be I mean there is no hard and fast uh format in the sense that basically you have to describe your idea and it should uh fit into the very high level format that we enforce by you know providing the headers right so this is why we

provide the headers this is why we have the bots so that at least you know that is the basic thing that we can enforce and apart from that I think it's more about whether your PR is sort of you know expressing it uh expressing your idea properly or not >> right >> is there something that you think can be structured I mean that would be sort of helpful if you have some points then >> sure >> we can discuss it in EIP IP meeting and so our way of doing things would be so can we sort of you know uh add these uh uh test at these checks in the B itself

because B is like a very uh you know uh iterative way of giving feedback right so you do something and B doesn't >> pass it will tell you why it didn't pass as well >> so in that sense I think uh that is the best way to deal about it but apart from that >> if you think that there are some examples that can be created but I mean all the ERC's that are out there are sort of examples only or EIP that are out there are sort of >> but but what what is exactly that you know for example so what are your exact suggestions like >> what >> yeah I mean I can I can definitely like write something maybe like you know set or however that works but I I think it's

actually to do with the test cases themselves like this was something I heard from a few other people as well and we we encountered during like while we were submitting the the test right like there's a lot of times where certain ones fail and like specifically that one with the where it like you know generates the HTML that is going to actually publish on the main ERC site, right? And that has like a bunch of different checks for you know like are all anytime there's like a ERC mentioned is it like hyperlink correctly to the like the ERC within the repo. Um there are like a few other like formatting things like they're like very specific items that aren't document anywhere but they're in the test. So I think like if there's something clear saying like okay

you know these um these are all the tests and this is exactly like what they're looking for and that's just like you know like posted as like documentation somewhere even on the GitHub whether it's the readme or somewhere else that would be really helpful because that test takes almost 20 minutes to run and like every time there's like one or two like small things right you wait 20 minutes and then you see like oh there's like some error but you there's no docs on it right so you didn't even know that that was like a formatting thing that you had to do and then you have to like rerun and make a new commit and like wait another 20 minutes. So I think that's like the main issue probably.

>> I think I believe you can run that test locally as well. So uh there must be some command I I'm sure there is a command that you can run locally and verify that uh you know your PR passes those those tests. You don't have to wait on the CI for that. uh but as such the general rules are already there because we don't add anything into CI test unless you know we have documented it on EIP1 or ERC1 right so >> uh are are are those things not present in EIP1 and ERC1 is my question then >> I think one or two of them it's just not

it's not very clear but I mean I can you know I can make a PR for this where I just like update the readme, right, and make a PR saying like, "Okay, here's like these extra docs." Just to like there's like one spot where someone can see all them, right? Rather than like having to dig through the like the full like the entire full documentation since like, you know, at least like the CI whether you're running locally or like, you know, directly on the actual repo. Um, you know, it would all just be in like one place. So, I mean, I could do that, but I don't know how long that will take to approve either, right? So, um it's not it's not that see I don't actually know right because there's so much on like the ERC1 that certain like small things maybe they got

missed but it's I guess it's just like not clear document anyways I don't want to waste your time but um yeah I think maybe like if it was all condensed in like at least for the tests in one spot in the repo that would help a lot of people that's all >> so I guess what what uh you are trying to say is that maybe we have one example which has all the features that we support and the CI passes so that you know people can look at it and see whether they consistent with it or not. I think that that could probably work and uh maybe puja we can add this in our EIP IP agenda that if we can generate uh a a sample uh EIP or DRC

where all the features are present and uh people can sort of use to refer it. I guess that would be helpful. >> Yeah, that that would be awesome. Yeah. >> Yeah, sure. Uh we can definitely add it. But uh Rohan as you suggested it would be a good idea to have a PR with respect to whatever changes you are talking about. And one more thing like I would like to add you mentioned ERC1 multiple times. I am not very confident that ERC1 is being actively maintained. When the repo split happened ERC1 was made as a copy of EIP1. Generally speaking we do not have a duplicate number for any of the EIP ERC and even for RIP. So my my recommendation would be to please follow

EIP1 instead of ERC1. You would find everything related to ERC's documentation in available in EIP1 as well. So even in future if you want to add some recommendation that could be helpful for many other authors to document their proposal. Perhaps we should make it in the EIP1 rather than going to ERC1. >> Yeah, that makes sense. I I know you guys changed it too. So I think that also might be part of the confusion like all you know like all these like small things like notes like these like that we should use the EIP one for both ERC and EIP. Um if that's like all in that git repo somewhere like with the sample and like some notes or something I think yeah like like you said like that would probably be really helpful. So yeah that

makes sense. >> Sure. >> Thank you. Yeah. >> Cool. Yep. Uh, hi Ben. Uh, do you want to bring something up or you just wanted us to bring your EIP in focus? >> Uh, just to bring the EIP in focus really cuz um, ideally I'd like to add it to um the meta EIP which is the 8007 which is the Glamsterdam Glamster Dam gas repricing.

So, I' I'd like to get it on the um agenda with other >> uh so I think uh >> 10579. >> Yeah, it's the last one. Oh, there is some CI still failing. Let me have a look at that. Oh. Uh, yeah. It's just the external image.

Um, I didn't update the IP for some reason. Seven. Push that. Yeah, it should be fixed. Ben is it possible that uh we don't do

our own indentation over here in terms of new lines because uh you know then the HTML renderer would basically be able to render it. I guess it will still be able to render it properly but uh I mean I prefer that you don't add any new lines yourself so that >> unless it's unless you are sort of doing a new line and sort of separating out the paragraph.

>> Yeah, understood. That's easy enough to change. Uh, one one thing I wasn't

entirely sure about that I think is correct. I suppose I could just look at other EIPs. Um so we're we're focused on um the idea of prividing test cases. Um but that doesn't really seem to to fit into a specific I don't know if it's security considerations that go in Uh can you sort of also add with

language? This is like how we do triple dash python or something like that I guess. Oh, this is just totally pseudo code. >> Yeah, that's just sort of pseudo code math. So I've got two two sections. The first one is like the maths that deals with it in um floating point numbers and then a second section which is integers cuz we don't like floating points.

Sorry. And also um yeah power of three Yeah. What exactly were you saying for

the test cases, Ben? >> Um, I wasn't sure where it lived. Um, I have it under security considerations, but I don't know if there's um Yeah, cuz um the you'll get a linting error if you add your own infection I suppose specification.

Yeah. Okay. Think that was my question. >> Yeah. So, what exactly do you want to do over here? >> Oh, uh move test cases into and uh reference implementation up into specification rather than rather than in security. I think we don't have any specific format to provide for test cases. Uh and yes, reference implementation. I think this is fine on a very high level.

Do you want to provide a very deep uh deep reference implementation or this is fine? >> Uh this is fine. uh I'm only providing it because um there are potential rounding issues and that would cause um consensus problems. So just to be exact on how to how to round >> I think you can you can just even move this to the spec you know you can move this uh to the spec itself. So you don't need them in the reference implementation because

reference implementation is like you know quite a complete kind of implementation where everything else is present. Uh so I guess you can also move it to the spec because that would sort of uh properly define the functions and the rounding things right. >> Yes. Yeah. >> Cool. Uh so once you have done some of the changes uh that I asked for let me just leave a comment.

>> Okay. Thank you very much. Once you have done this, I'll just uh go through it again and uh then uh I can just approve it. Everything else looks fine to me.

>> Thank you very much. >> Very well. >> Thank you. >> Very well. Um in the m meantime I took liberty to take a look at the EAP board and there are 36 PRs which are listed and most of them are on consensus side like editor's consensus which I don't think we will be in a position to review it here today and some of them are typo which again are waiting on author's uh response in order to move forward. The proposals which were added as draft has already been reviewed by Yuga Jender. I think in less than an hour I saw comments on each one of them. So I believe we are good for today. Uh today's agenda like the PRs which are

there for review is all um taken care of. >> Yep. I guess we can uh yeah finish up this session. >> Yeah, a little early today. Thank you everyone for joining in here. Next week on Tuesday um at 1600 UTC we will have another editing office hour. So please feel free to add your PR. We already have an issue open on Ethereum/PM repo for that um meeting. Thank you everyone for joining us here today. Goodbye everyone.