Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

EIPIP Meeting 111 #365

Closed
20 of 30 tasks
poojaranjan opened this issue Oct 16, 2024 · 6 comments
Closed
20 of 30 tasks

EIPIP Meeting 111 #365

poojaranjan opened this issue Oct 16, 2024 · 6 comments

Comments

@poojaranjan
Copy link
Member

poojaranjan commented Oct 16, 2024 •
edited
Loading

Date and Time

November 20, 2024 at 14:00 UTC December 18, 2024 at 15:00 UTC

Location

Zoom: TBA in the Discord #eip-editing channel

YouTube Recording: EIPIP Meetings

Agenda

1. Discuss Open Issues/PRs, and other topics

Edit to Final Proposals

Update to EIP-1

Other topics

Call for Input

Call For Input Status Inclination/Result Deadline
#367 Open 1 Editor responded, opposed Dec 04, 2024
#368 Closed @gcolvin is moved to emeritus and removed from the yaml files. Dec 04, 2024
#369 Closed @axic is moved to emeritus and removed from the yaml files. Dec 04, 2024

2. Other discussions and updates from past meetings

3. EIPs Insight - Monthly EIPs status reporting.

Screenshot 2024-12-17 at 10 15 28 PM

4. EIP Editing Office Hour

  • Agenda 49 Video 48

5. Review action items from earlier meetings

Next Meeting date & time - Jan 15, 2025 (3rd Wed of the Month) at 15:00 UTC?
@PowerStream3604
Copy link

Hi @poojaranjan , could you please add ethereum/ERCs#663 ?
All comments are resolved, and it would be great to have another round of review to get it merged.

Thank you!

@poojaranjan poojaranjan mentioned this issue Nov 24, 2024
Closed
16 tasks
@SamWilsn
Copy link
Collaborator

Do we want to formalize https://hackmd.io/@SamWilsn/B11QmJoq6 and if so, as an EIP?

@abcoathup
Copy link

Do we want to formalize

Style guide is good (though I prefer onchain rather than on-chain).
Can we get an AI to report on issues in the validator?

Can these be added to EIP-1 style guide section: https://eips.ethereum.org/EIPS/eip-1#style-guide

@viwinkumarpadala
Copy link

Hello @poojaranjan ,
I want to share a demo of new tools that we have added on our website and are helpful for editors, authors and everyone:

@SamWilsn SamWilsn mentioned this issue Dec 18, 2024
Open
9 tasks
@poojaranjan
Copy link
Member Author

Summary

1. Discuss Open Issues/PRs, and other topics

Edit to Final Proposals

Update to EIP-1

ethereum/EIPs#9130

  • @SamWilsn shared that mostly these are typographical and clerical fixes suggested by a potential editor
  • There is one more PR on top of this, so other editors may look at it tomorrow.

Other topics

Revisiting EIP Type
https://eips.ethereum.org/EIPS/eip-7783
https://eips.ethereum.org/EIPS/eip-7790

  • @poojaranjan explained that both of these proposals were added as Informational, but it seems they could have been combined into a single EIP with a different "Type".
  • @SamWilsn inquired whether this change applies to all clients working at the consensus level or if it is a per-validator strategy that they can choose.
  • @Giulio2002 shared that this was initially proposed as Core, but someone recommended moving it to Informational since it is a recommendation of strategy. This describes how a validator chooses the gas limit at the client or UX level, not at the protocol level.
  • @SamWilsn suggested that it could be categorized as Core and asked for other editors' opinions.
  • @g11tech expressed agreement with the current categorization (Informational) or suggested it could potentially be Meta.
  • @poojaranjan pointed out the presence of a "Security Consideration" section in this proposal, which is typically absent for an Informational Type.
  • Additionally, to move this proposal to "Final" status, if client implementation is required, it should not be classified as Informational.
  • @Giulio2002 mentioned uncertainty at this point about whether all clients will implement it, though clarity may emerge in the future.
  • @SamWilsn and @xinbenlv agreed that it should not be categorized as Meta.
  • @g11tech raised the question, "Why not Standard Track?"
  • @poojaranjan supported the Standard Track categorization and suggested consolidating the two proposals into one. Whether or not it is included in Pectra should be discussed in the ACD meeting; for EIPIP, the focus is on determining the correct "Type" for the proposals.
  • 3/4 editors agreed to move these proposals to Standard Track - Core and consolidating them into one EIP seems logical.

Next step - @Giulio2002 will make a PR to move the proposal as one Standard Track EIP

Upgrade Meta

  • @poojaranjan : Historically, upgrade EIP list has been added as Meta EIP. It was stopped for some time but is back in the process again. Following the definition of Meta EIP, and looking into EIPs it looks like Upgarde realtaed EIPs are more suited for "Informational" type. What other editors think? Adding one more point is that Meta EIPs are generally for "Process" and "Upgrade EIP" is more like an info not a process.
  • @SamWilsn : Just because it is grouping of EIP, it can be a Meta EIP, but it is not a process recommendation. Only thing that tip the scale is "unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them." This make it sound like Meta but I am okay making them Informational or Core because this is the kind of things that happens to clients.
  • @poojaranjan : I noticed, but my argument is that implementations are already done via EIP, Upgrade EIP is just a list similar to EIP-7675: Retroactively Included EIPs where the list is to maintain Core EIPs added to Ethereum out of upgrades.
  • @SamWilsn , @g11tech @xinbenlv seem okay to have Upgrade EIP as Informational in chat.
  • @xinbenlv: Traditionally, it is included in Meta and can be confusing for users if we change type.
  • @poojaranjan : Indeed, but we should remember that it was dropped for a few years. Now that it is back, and I think it can be fixed, if it is a mistake. and if not, then perhaps EIP-1 can be edited to allow Upgarde EIP added as Meta.
  • @SamWilsn: What if we redefine Meta as purely related to the EIP process, and move all of them to informational?
  • @g11tech i like these EIPS, we can info category
  • @xinbenlv: That feels slightly introducing too much of new process.
  • @poojaranjan : I am fine either move all to Informational or edit EIP-1 to keep it in Meta.
  • @poojaranjan: I think, EIP-7723: Network Upgrade Inclusion Stages talks about the process and can be Meta, could be kept as Living as well. Should we open a "Call for Input" for this?
  • @SamWilsn: Is the consensus to move these things to informational and redefine meta as purely EIPIP?
  • @g11tech: +1
  • Bumblefudge: Yes, and I agree. They all seem Informational. The definition for Meta is "EIPIP". A "Call For Input" make sense.

Next step - @SamWilsn will make a "Call For Input".

Adding non-core EIPs to the Upgrade Meta

  • @poojaranjan: Historically, Upgrade EIP list contain only "Core EIP" and not "Networking" or any other category.
  • "Core" is differentiated with any other "Standard Track" EIP with the fact that it will be deployed with an upgrade.
  • @g11tech: Yes, I would like these things to be collated so yes.
  • @SamWilsn: if Networking EIP is applied at the time of upgrade, then it make sense, otherwise no.
  • @g11tech : If it requires hardfork kind of coordination, then it make sense to include in Upgrade EIP. For Networking EIP, we need to decide on per EIP basis whether they belong to "Upgrade EIP" or not.

Next step: Update EIP-1 to reflect the decision that Networking EIP can be listed to "Upgarde EIP" list when it is critical for an upgrade and requires hardfork kind of coordination. eg PeerDAS & FullDAS.

EIP-7675: Retroactively Included EIPs - Thoughts "Meta" or "Informational"?

  • @poojaranjan: I left couple of comments a) Not sure if the name of the proposal is appropriate because "Retroactive" gives an impression that it is added after an upgrade. But, in reality these have nothing to do with the order, they can be added before or after any upgrade as they don't need to be added in sync.
  • @SamWilsn: If they have to be applied from "Genesis" then, "Retroactive" make sense; but if not all have to be from the "Genesis" then "Out of band" would make sense. I also don't like this because this will never reach to "Final"
  • @poojaranjan: yeah, we can perhaps keep it "Informational" and "Living".
  • @SamWilsn: According to EIP-5069, we don't maintain list; so I'll open a CFI to Withdraw this.
  • @poojaranjan: That has a strong argument.
  • @SamWilsn: Our process isn't designed around things that get updated constantly. We'd like to getting it to an "Immutable" state.

Ref (EIP-5069): "We want all proposals to eventually become immutable, but a registry will never get there if anyone can keep adding items. To be clear, exhaustive and/or static lists are fine."

Recent change from ACD Meeting: Merge the Declined for Inclusion addition to ethereum/EIPs#9056

Thoughts - ethereum/EIPs#9126

  • @poojaranjan: I am unclear on the inclusion of "DFI". What editors think about it?
  • @SamWilsn: seems reasonable to me. This is per fork, so it make sense.
  • @xinbenlv: If rejected once, when can they come back?
  • @SamWilsn: the next upgrade
  • @poojaranjan: Where can we find this, in Upgrade Meta?
  • @g11tech
  • @SamWilsn: EIP-7723: Network Upgrade Inclusion Stages just describes how "Upgarde EIP" should look like. There will be no change in preamble.
  • @poojaranjan : So when we move to "Testnet" then it will be "Scheduled for Inclusion", when upgrade happened the "Included"?
  • @SamWilsn : These documents are separate from EIP statuses.
  • @poojaranjan: Agreed, but I think we should have clarity on when to move stages. PFI -> When proposed to devs, CFI -> When accepted for Implementation, SFI-> when on Public Testnet, Included -> when deployed.
  • @SamWilsn: yes, the proposal 7723 hasn't been considered as an official Meta EIP that can be enforced.

Call for Input

  • Greg & Axic have been removed as editors and permissions removed. They are welcome to join back.
  • ISO4217 - is a standard that defines the country code, but the standard isn't free, so we can't allow links to it. I am opposed. Other editors please comment. I'll close it later today.

2. Other discussions and updates from past meetings

  • @poojaranjan: What people think about formalizing the process?
  • @SamWilsn: leave a comment and I will open Call For Input to add it to EIP-1 and we can approve it there.
  • @poojaranjan: I feel like Sam's hackmd is a good fit for What belongs in a successful EIP? as it will help new authors to learn about Do's & Don'ts and document the proposal. Whereas part of "Onboarding" hackmd can be added to EIP-5069: EIP Editor Handbook and a mention in EIP-1 to check EIP-5069 for Editors Guideline.
  • @SamWilsn: I don't have a strong preference where it lives.
  • @poojaranjan: Editors were okay having these added in EIP instead of hackmd.

Next step: Bring PRs by the next meeting for consideration.

EIP Numbering

  • Follow the Discord Thread Recommended to use the numbering process as a good practice.

3. EIPs Insight - Monthly EIPs status reporting.

Next Meeting date & time - Jan 15, 2025 (3rd Wed of the Month) at 15:00 UTC

@poojaranjan poojaranjan mentioned this issue Dec 19, 2024
Open
11 tasks
@poojaranjan
Copy link
Member Author

Closing in favor of #375

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@abcoathup @poojaranjan @SamWilsn @PowerStream3604 @viwinkumarpadala