EIP Editing Office Hour #89 (EIP Only)

Transcript

[music] What's up?

>> [music] >> It's okay. >> Heat up here.

>> Heat. Heat. [music] >> Learning in progress.

Welcome to EIP editing office hour meeting number 89. This is a GitHub issue on Ethereum PM repo. The number is 1928 on agenda. We have u only PRs from EIP repo. Some of them are from other section and most of them are on draft. So we could we are going to be reviewing all these proposals along with editor Gajender Singh. Thank you Gajender for joining us here today.

>> Thank you Pujo. So let's get going. >> Yep. I see that you have already covered most of them. Um but uh after that I noticed some of the PRs like authors have also responded back including me. >> All right. So cool. Let's start looking. >> Yeah. Yes. So here my question is do you want it to be other way around like only listed for living and final and not for others?

>> Yeah. This is this is what this is what I was trying to say because I mean having this positive signal is like a confirming signal and uh rather than other way around you will always be confused okay you know did the guy actually missed uh putting in uh putting in the status or is it actual final right so I think when we explicitly say that this is final diving is more uh reinforced ing and uh more upfront. >> Yeah, I mean I'm fine by the idea but just wanted to mention two points here.

So when we are looking at any proposal, we do have this status tag on top of the page. I mean if you can scroll up I have shared the example how does it look like on a page. So yeah so that's yeah so here also it's mentioned live meta and then on the bottom we are adding that as citation. So it's kind of like adding it on both ends. Uh so people will know or not >> right sideish like I mean if someone is opening the page of course they will get to see the latest status.

>> Mhm. But I mean if is this document is just cited somewhere then people will just look at it and say okay >> it's living nice >> so this basically without me following the link I can basically say that okay this change has been adopted by the community and uh uh so it's great I can it's a basically high quality signal that is how I view it. >> Yep I agree to that idea. Um however u I am not sure if all editors are on board with it. Would you recommend me to open a call for input or do you think um we could just discuss it in EIP meeting?

But I don't I'm not sure if all editors will be there. So yeah, what would be your next step recommendation here? >> Yeah, I think call for input makes sense because uh it's a more formal way to get the final vote of the people. Very well. In that case, I will go ahead and create a call for input for triple 98 PR. >> Yeah. I mean, it's sort of an UX sort of a UX issue, right? For people. >> Yes. Yes. >> And I prefer that, you know, if I look at citation and I get this high signal that is already a living or a final IP, then I will go and check it out and not waste my time on something that I don't know the status of. But if it's

interesting to me, I I can always go to the link and uh check the final status. >> Yeah, initially when I uh updated it, my idea was to include all the statuses. Same as on top, people can see it on bottom like in citation if they find it is living it. It's not a draft or last caller review, they would know that it is not something to be adopted as it uh but Sam recommended that. >> Yeah. Yeah. problem with including other statuses is that uh basically they are changing right so yes leaving and final is a final status and if the status is missing then the person will automatically go and check the status >> okay makes sense to me all right I will

go ahead and create a call for input and then we will decide on this PR >> I mean that is how I want to see it but of course people and other editors might have a different take so >> we'll basically see in the call for input Of course. Um so the next one is uh website update. I believe Sam has already approved it. This was again a bug. Uh in this bug the withdrawal reason was not being showcased but since this is a big change uh it requires approval of two editors.

>> Yeah I'll just go ahead and approve it. For the next one, I'm wondering if it is closed by mistake or like it's decided because I noticed that the call for input is still open and I believe you were in favor of uh having that in

citation. Yeah. I mean, uh, I thought to be closed meant that >> Yeah. Yeah. >> This needs to be closed. >> No, no, that was for the bottom one. So, yeah, I assume that it could be by mistake because the call for input is still open. So, maybe if you can open it if it is possible. Yes, thank you so much. We'll wait I till the end of the call for input and based on that we can >> Yep. >> make action on this one. Rest three are closed. Those are all good. I believe the author has made some updates on 9374 which is the next one.

Uh, is it is still having CI issues? >> I mean, it's not having CI issues, but author is not removing these additional lines. I mean, he's not complying with them. I don't know. >> Okay. Okay. Yeah, I noticed there were some file changes, so I let it live here in the agenda. I mean, I'm always a bit hesitant about

accepting big files because you can't basically review them. >> That's correct. Yeah. >> Yeah. Not even pseudo code, right? So, >> okay, maybe we can let it live here for more editors review. We are having reviews almost every week now, >> right? I want to see the changes made in the EIP. me. Okay. So, this comment is not yet

resolved. >> Mhm. Yeah. Over here as well.

All right. Yeah. Seems like uh there is some error as well. Yeah, definitely this pair need more work.

next to I believe you have already reviewed it but maybe we can take a quick look if we have Yes. Yes, that one if we have anything else. Yeah, I think on this I'm >> still waiting for Leon Africa to >> basically respond that whether this EIP is why should not be just a contract rather than an EIB.

This particular EIP uh is regarding adding witnesses I think in the block but uh I've asked GM who's basically looking at the stateless initiative itself and has uh so was doing uh stateless circle and so based upon his input uh we will see how to go with this particular PR. That makes a lot of sense. I mean editors are looking into only editorial edits uh and formatting issues. It would be a good idea to get experts involved as well. So the next one here is again my EIP. I have

responded to your question and I have also cited a couple of other EIPs. Um, one which is already merged as final and one which probably will be following the same path if that u kind of like satisfies the query. We can take a look at the proposal. I believe this was also produced in another office. I agree. I sort of agree to what you're saying that I'm saying that you know uh so this this is doing that it is basically recording the nomenclature process.

>> Mhm. which is fine but I'm like my question is whether it should be a final or a living EIP because and I I'm just saying that uh we should have it as living because we should try to minimize the EIP block we have on processes because when people are looking through the process EIP they just want to understand what is the current process they don't want to go through 10 EIP to figure out okay this has changed and this has changed and then this has changed >> as much As I agree with your idea, Nachender, I'm not sure if all other editors will be on board with the idea of living. So, as an author, I would be fine if it is moved forward. Uh well, a living and final status has to be

decided when it goes into review status. Particularly, I don't see a blocker to be merged as a draft. Uh that is something that we can perhaps discuss when we are moving from this status to another. But again I would >> sort of add that comment somewhere that you know this maybe as a to-do section in the EIP itself that we need to figure out what is the final status so that when we are trying to do that when we are trying to move it from the draft to some other status we basically have this discussion or at least create a >> call for this yes I would do that yes >> because I don't think we can add it in the proposal anywhere so I will just go

ahead and create a call for input for this one >> and uh this the CI is still failing. >> Okay, let me take a look at that one. Maybe you can look into other peers and in the meantime I can take a look into why CI is failing. Maybe the space error >> because of the links. It's because of the links but these >> but this link is allowed right it's already allowed execution specs. Yes, but it might not be in the format that it might be expecting it to. >> Okay. Okay. I will take a look at it because I have tried to use particular commits for these I guess. Yeah.

>> So, it's it's basically saying that it I think wants star instead of dash over >> Yes, I got it. Got it. Got it. My bad. I'm going to fix it. All right. Thank you so much. It's helpful. So in the next one again yes I have also responded to the query uh I believe this was also answered in the BPO1 itself. So the uh proposal in which the process is documented is anformational EIP and it does not talk about like what parameters changes are included. So whenever we have a new upgrade whether it is parameter only upgrade we have

meta EIP and this has been seen historically with uh upgrades >> I sort of so I am so my question is not that why they there are individual EIPs I'm like my question is why are they meta >> oh because they are hard fork meta so for any upgrade there has to be >> no no they are not hard fork meta They are heartfa is like okay this is the heartfog this is going to happen at this time >> and these are the EIPs that are in it but this is not that this is actually changing config configuration or basically uh the actually uh parameters of uh

>> blobs >> of right so >> so this in my opinion is not a metaip this is a standard uh rack >> right. Uh so um the reference that I have cited here is earlier in the days of P we used to have hard forks which was one parameter change only to move the uh push the ice age right so that was just changing one parameter and for each upgrade we have hard fork meta so in a similar fashion if we are moving here here we are changing more than one parameter so that's why we think that it is useful to give the stature of hard work meta for these upgrades.

Uh and this is explained in u yeah vo1 uh fellowship of ethereum magician page. Uh I have added the link here. >> This one? >> Yes. >> Oh, has the same. >> Yes. Yes. Yeah. I mean like it's a historical context and that's why I believe that you know upgrade nomenclature thing is very important. So people get to know all about all upgrades and they can access each file at one place.

I think all of these PRs are from same time when I was working on one thing one thing led to another and then I started documenting everything. No, then it makes sense because everything is green. So BPO3 I think once BB2 is merged then

I'll approve BPO3. >> Yes. Um Yep. Uh yeah, I have also addressed the todos that you have mentioned as a comment for BBO3 and for this one I believe your comment is the last comment and we are waiting on author's response. Let's look at BB3. >> Next one is the sidecar 11254. Okay. Yeah, we can take a look. And uh >> yeah that is the same discussion I think.

>> Mhm. Uh but I believe you also recommended adding to rules here >> which makes sense. So I have updated it. >> Cool. I think uh this must be dying because BB2 must be >> it is still not merged. Yes. But anyway, I'll just approve it if you >> Yeah, I can fix it. Next is Yeah. Sidec cars. I believe uh

>> Tony has >> Yeah. No, no, the side car. Yes, that one. Yeah, >> Tony has added updates after your comments. Yeah, it all looks good.

And I believe that is the last one because the the one that is pending 1128 is waiting on author's response after your review earlier review. >> Got it. >> Yeah. So we are all done for the day. Uh but we have EIP boards. Obviously we have a lot of open PRs. Um I I'm wondering if uh there is any kind of preference in selection going forward.

Um like I don't see too much value in just typo PRs adding here for office hour. So if if there is any kind of >> yeah otherwise yes please >> what we should now what we should now do is basically if we should uh put an open claw or some other bot basically that continuously reviews the PR because it can just read the IP1 guidelines and take care of uh most of the things and uh once people are not able to resolve it then they can either come here or you know those those are things where those should be propagated to the editors. I think we

need to make this chain now uh so that we move to a better way of editing and uh we'll be able to uh respond faster as well as uh handle a better throughput of uh EIPs. >> I totally agree and I'm glad that discussion has already started. So I'm traveling to Denver as well hoping to talk to some more teams over there and maybe with uh DI team to like kind of work around tooling that could help speed up this process. So yeah.

All right. Uh that's all for today. We are going to add agenda for the next EIP editing office hour. Please stay on lookout for agenda on Ethereum/PM repository. Thank you everyone for joining us here. Thank you Gajend for your time. >> Thank you. Byebye. >> Bye-bye. >> Wonderful.

Thank you.