EIP Editing Office Hour #85 (EIP Only)
EIP Editing Office Hours · 20 Jan 2026 · 24:10
Meeting 85 of the EIP Editing Office Hour, held on 20 January 2026 and limited to core EIPs. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process.
Topics
From EIP Editing Office Hours, hosted by ECH Institute.
Transcript
Loading developers...
Heat. [music] >> [music] >> and get started. Maybe we can search
over there. >> Recording in progress. Welcome to EIP editing office hour. This is meeting number 85 and this is going to be EIP only. We have a few items added to agenda. Um and we are joined by editor Kajender Singh. Thank you Gajender for joining us here today. Maybe we can start with the PRs for final.
EIP Editing Office Hour Introduction
>> Yep. Thank you Puja. Yep. Let's do that. Gender if you would want to refresh.
Okay, I can see it is visible on your screen as well. All right, the next one is I believe I have added four or five EIPs and we have received uh approval from three of them. So may not be completely ready to be merged today. All right. >> Uh so basically what is uh stopping >> uh I think there are um the approval is requested by the authors uh of these uh EIP and out of five EIPs we received three EIPs approval already. It's just from moving from last call to final and
all these proposals are merged with Fusaka. >> Um but uh there seems to be it seems that the boat is failing on this particular EIP. >> Uh which one is that? >> 7951. Okay, let's take a look at 7 951. And that has been approved already. Is there a way to figure out what is wrong? Uh because um on my screen I can see it only requires approval of editor like you are one of those editors listed here.
>> Yeah, that is fine. But uh if the CI will not pass then it will not get merged. So the CI error says code block style expected fenced. I don't know what that means. Is there anything that we can let author know because the author has already approved it? >> I mean it's weird that uh without uh CI passing earlier it would come to this particular stage. I'm not sure maybe just re-triggering the CI will help.
>> Okay. I going to anyway approve these EIPs. >> Mhm. >> And hopefully maybe it will retrigger the CI. >> Okay, that sounds good. Yeah, because I was trying to be sure that there is no 7 and51. There is no open EIP or PR. um before making these requests. So for now I can only see um PR number one 13 which is the present one has 7951
mentioned. There is no other PR open >> right? uh you open these PRs, right? >> Yes. >> I mean, in general, I think uh we should do it PR-wise because we should do it EIP wise so that you know it's a bit easier to review and uh not be stopped by these kind of uh issues if one EIP is blocked.
>> Okay. So what I'm going to do is I'll follow up with the rest of the two authors and uh even after their approval this is blocked then I will resurface this PR for discussion and yeah we'll see what we can do about it. Will that help because I know it may be blocked by other two as well. >> Yeah. So uh I think uh the bot re-riggered that particular CI and uh we can come back to it later on and see. Oh, it's failing already.
Discussion on Miscellaneous PRs and CI Issues
Because if you look into the file there is no other change than just changing the status and removing the last call period. So I'm wondering like uh if the file is exactly same how it could pass pass to the last call and just show error in final. >> So it can happen that we updated our CI and uh some rules got updated and basically then this EIP is no longer complying to those new rules. >> Okay, maybe we will bring it to Sam's attention tomorrow.
Yeah, I think that makes sense. >> Okay, I'll make a note of the phone. Cool. In that case, we can move forward with uh miscellaneous PRs. >> Yep. This seems to be a small change and the author himself yeah have made the changes.
>> Yeah. again uh I think we sort of need to discuss it and can you make it an agenda item for tomorrow because CI needs to be fixed over here because every time an asset is changed it just flags uh editor for it I delete should basically uh flag the author for it if it's in draft or any other stages in which the author should be flagged >> okay so 15 and 1 both of them will be moved for CI flag.
>> Cool. >> So I approved it. I think this will get merged. But my point is that these uh this particular PR should uh just >> automerge, right? >> Yeah. Automerge because >> author created it. Yeah. Yeah. We are already with very big number of open PRs. We don't want these kind. Yeah. And it's also, you know, basically uh it's also sort of a roadblock for the authors who are doing these changes because they have to wait for someone to review them.
>> Mhm. Yep. That makes sense. >> So rest of the miscellaneous I'm not sure what to do about them, how to take care of that. So just have added that maybe if you can take a look at the first one see if we can address it in this meeting. I mean these are mostly uh the CI related or you know so these are best or the rendering or uh EI the website rendering related things and uh I think it's best that uh Sam basically looks into it.
>> Yeah, that was my understanding. That's why I just suggested that take a look at the first one. Uh otherwise we can skip this entire section and move it to tomorrow's meeting. We can move over to the draft now. >> Yep. And this particular basically PRI already approved uh but it's a typo and it's waiting on uh author as well as it's waiting on one more EIP editor it seems and uh again you know I think uh puja maybe you can get uh access to just you know finally merge uh the type of PRs because these keep piling up and uh it just easier to
just merge these typo PRs. >> So you're suggesting that we should uh allow direct merge to these typo because you know I'm actually looking at EIP insight and this number has like exploded of typo PRs. >> Yes. So it is basically it is uh I mean it would be difficult for the bot to say that these are type of PRs and maybe the bot and AI tools can deduce that but I think um if either uh force merge capabilities granted to me or to you. So what we can do is basically we can just look at them and uh in one of these particular sessions when you bring these
things up. Uh so I already for example has have approved that this is a type of PR and we can merge it and uh if for example you have the admin access then you can just merge them right away without waiting for authors or for any other editors because uh this this is just uh work piling. it is it is useless work and we can just dispose of PRs by merging them. >> Yep, I totally agree. I have brought up this uh discussion item in the previous EIP IP meeting and I believe as one of the action items uh Sam was supposed to check with the Ethereum Foundation team if this access can be granted to you or to the new editor Yohham. Um I have also
um mentioned this again surfaced this again in this call for input that is added recently to add associate EIP editors. Uh hoping to hear something about it. I really believe that if we get more permissions to existing editors we can decrease the number of open PRs. >> Yeah. >> Yeah. We'll bring it up again tomorrow. See if there is any progress in that direction. All right. So this is move from stagnant to draft as well as uh
>> the change of handle of author and I think the author is same. So it can be done. >> But how how do we know the author is same? I don't know. Ben himself has done it like he just approved another PR to a PR which was a proposal to move into final. So maybe we can look into his u GitHub repository. Ah okay okay now I [clears throat] get it what you're saying. I mean, can he get the other author to sort of uh approve?
>> That's a good suggestion. Maybe we leave a comment for that. That's a very good suggestion. >> Oh, so he is uh so the new handle is also part of Nethermind uh organization. So it's uh it seems it is authentic. Mhm. So I think there is anyway uh one more review that will be required from one of the previous from Gileio and uh so I can just approve it I think. Yeah, maybe we can like ask Ben to give Okay, because Ben has [clears throat] already created this one and he is replacing himself
from author. So, he may not be able to approve it anymore. So, yes. >> Yeah. So, it's fine. Basically, one more. So, the second author will need to >> approve that. Yep. Okay. Cool. >> So, it solves a confusion regarding the authenticity of the handle. >> That makes sense. And uh this new IP for ME mess protocol
I already merged. Okay. So, seems like author has done the change that I requested >> 49 ago. So, >> yes. Uh I mean after your review. Yes.
Yeah. It was pending after your review. So, I thought we can get it cleared today. >> Yes. Sounds good. Yeah, in this uh PR as well I added a
small net to add a to-do marker and uh when the author will do that this PR we can also merge because everything else looked fine. >> So this this is just to mention to-do in the proposal right now because this is for the draft status. >> Yes. So generally wherever there is a TBD uh authors should put a HTML 2D marker because that is a marker that is tracked by our bots when it when the proposal is trying to move to review and the bot can basically flag it if you have not addressed it. So it's a handy tool and uh makes it easier for people to fix things and to not forget them.
Proposal Review Process and TBD Marker Tracking
But another I I think I item that we can add to tomorrow's EIP IP meeting is that uh even without the marker if there is a TBD then that that's that is something that bot can bot should track too because most of the people write TBD by default and uh it is just easier if we are tracking it rather than asking them to add to-do markers because most of the people don't add it and it is it just adds unnecessary to and protime for EIP rating.
>> That is a very good piece of information and yes we can add that it's simpler to just add to plus TBD like either of them is possible. So I think that is pretty much for today. Um I know there [clears throat] are like too many open PRs but it is very diff it is very challenging to segregate them. I have noticed most of the PRs are actually waiting on author's approval which are the sensible PRs other than typos and all. So I think this meeting is going to be pretty short for us today. I really hope that we get approval for proposals of Fusaka then we can move them to final and uh I would actually uh require some
kind of suggestion uh in terms of listing these PRs for review. Um what would be your general recommendation as you are seeing these peers every day? >> Uh recommendation regarding what exactly? >> Uh recommendation to add them in this list. I mean as we can see that we have around 370 or 80 peers open uh 380 actually and for today's meeting I could list only 10. So only those 10 made sense to me or 10 or less. No, it's more than 10.
But uh we should be in a position to add. >> So they were only there were only 10 puja because uh I did I basically every starting of every week or in the middle of the week I do all open uh uh open notifications review and basically you know address them. uh and even before today's meeting I did that in the morning and that is why basically lot of these things were already addressed but yes I think uh the other open PRs uh would be waiting on authors or they would be type of PRs that uh we we can't merge or something that is requiring force merge and uh so I think uh maybe
we can also add a label like force merge to these PR as where you know I can when whoever is basically reviewing that they can add the label. So basically any IP editor can add the label and uh so it basically will help segregate those PRs out. Uh so I think this would be a useful tool where you know EIP editors can also add the labels when they are reviewing something if that is uh basically you know if they can categorize the PRs into something that we already have the workflow for.
>> That makes a lot of sense. All right I'm going to add that as an agenda item for tomorrow as well. And yes, I noticed that most of the peers were already reviewed before the meeting and that's why I did not list it and removed whatever were listed earlier. Thank you so much uh dender for taking out time. I just want to uh before we um end up the meeting for today, I just want to give an opportunity to anyone here if they have any question for editor please share them otherwise we should be good for today.
Cool. Uh in that case maybe we can um wrap it up right over here. See you all tomorrow in EIP meeting. Thank you Gender. Have a great rest of the day everyone. >> What's up?
>> Thank you. >> Heat. Heat.
Heat. [music] >> Heat up here.