Skip to content

enhance(ci): Add EIP Tracker Issue Template #1847

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

Open
marioevz wants to merge 8 commits into
base: forks/osaka
Choose a base branch
from
Open

enhance(ci): Add EIP Tracker Issue Template #1847

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
4852cfe
enhance(ci): Add EIP Tracker Issue Template
marioevz Dec 4, 2025
75b7ae0
Add note and paraphrase.
marioevz Dec 4, 2025
abf6055
Update .github/ISSUE_TEMPLATE/eip-tracker.yaml
marioevz Dec 5, 2025
691545c
Update .github/ISSUE_TEMPLATE/eip-tracker.yaml
marioevz Dec 5, 2025
000279d
Update .github/ISSUE_TEMPLATE/eip-tracker.yaml
marioevz Dec 5, 2025
1d0d104
Update .github/ISSUE_TEMPLATE/eip-tracker.yaml
marioevz Dec 5, 2025
7d28961
Review feedback
marioevz Dec 5, 2025
c19ad02
Update .github/ISSUE_TEMPLATE/eip-tracker.yaml
marioevz Dec 5, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 81 additions & 0 deletions .github/ISSUE_TEMPLATE/eip-tracker.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
name: "EIP Implementation Tracker"
description: "Track specification and testing progress for an EIP"
title: "EIP ${{ form.eip_number }} Progress Tracker"
labels:
- A-spec-specs
- A-spec-tests
- C-eip
- C-test

body:
- type: input
id: eip_number
attributes:
label: "EIP Number"
description: "Enter the EIP number (digits only)."
placeholder: "e.g., 8024"
validations:
required: true

- type: input
id: eip_title
attributes:
label: "EIP Title"
description: "Copy the title from the EIP."
placeholder: "e.g., Backwards compatible SWAPN, DUPN, EXCHANGE"
validations:
required: true

- type: dropdown
id: fork
attributes:
label: "Fork"
description: |
Specify the target fork **only if the EIP has reached the CFI stage**.
More info: https://eips.ethereum.org/EIPS/eip-7723#considered-for-inclusion
options:
- TBD
- amsterdam
- bogota
validations:
required: true

- type: markdown
attributes:
value: |
## [EIP-${{ form.eip_number }}](https://eips.ethereum.org/EIPS/eip-${{ form.eip_number }})

### Target Fork

Fork **${{ form.fork }}**

### Instructions

- [ ] Assign issue to EIP specification and testing owner(s).

> [!IMPORTANT]
> A specifications specialist and a testing specialist should ideally share ownership of the EIP.

- [ ] Add the issue to the target fork milestone if applicable (i.e., the EIP is at least in the (CFI stage)[https://eips.ethereum.org/EIPS/eip-7723#considered-for-inclusion]).
Copy link
Contributor

@fselmo fselmo Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

broken link styling I think

Suggested change
- [ ] Add the issue to the target fork milestone if applicable (i.e., the EIP is at least in the (CFI stage)[https://eips.ethereum.org/EIPS/eip-7723#considered-for-inclusion]).
- [ ] Add the issue to the target fork milestone if applicable (i.e., the EIP is at least in the [CFI stage](https://eips.ethereum.org/EIPS/eip-7723#considered-for-inclusion)).


### Specification + Testing Status

- [ ] Testing complexity assessed and documented.
- [ ] Specification implementation merged to `eips/${{ form.fork }}/eip-${{ form.eip_number }}` *(skip if the fork branch merge below is already complete)*.
- [ ] Specification updates merged to the corresponding `forks/${{ form.fork }}` branch.
- [ ] EIP updates proposed in case of architectural choices surfaced during implementation.
- [ ] Required testing framework modifications implemented.
- [ ] Test suite implemented.
- [ ] Full code coverage for all changes.
- [ ] [Testing checklist](https://github.com/ethereum/execution-specs/blob/HEAD/docs/writing_tests/checklist_templates/eip_testing_checklist_template.md) complete.
- [ ] No regressions or failures in tests from prior forks (including static tests).
- [ ] Hardening session completed.
- [ ] Benchmarking performed and results documented.
- [ ] Ran tests using `execute` to ensure compatibility, and marked specific tests to be skipped when they cannot be executed on live networks.
- [ ] Added Mainnet-marked tests ([example test](https://github.com/ethereum/execution-specs/blob/2a6f9ee98ba7c0d04c7d523a0ea0ee8a98a5c418/tests/osaka/eip7939_count_leading_zeros/test_eip_mainnet.py)).

### Process Status

- [ ] Hive tests passing on all implementations.
Copy link
Contributor

@spencer-tb spencer-tb Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be nice to make this more granular.

Suggested change
- [ ] Hive tests passing on all implementations.
- [ ] Hive tests passing on all implementations:
| Client | Engine | RLP | Sync |
|-------------|--------|-----|------|
| Geth | [ ] | [ ] | [ ] |
| Nethermind | [ ] | [ ] | [ ] |
| Besu | [ ] | [ ] | [ ] |
| Erigon | [ ] | [ ] | [ ] |
| Reth | [ ] | [ ] | [ ] |
| Nimbus-EL | [ ] | [ ] | [ ] |
| Ethrex | [ ] | [ ] | [ ] |

Copy link
Member Author

@marioevz marioevz Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this is too much, we could instead create another template.

But even this single bullet-point I'm not completely convinced we should put it in here because it's such a fluctuating state. E.g. we could introduce new tests that break implementations, or a client might have a regression. Do either of those mean we have to come back here and uncheck this checkbox?

Copy link
Member Author

@marioevz marioevz Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After thinking about it, I feel we can make this point a bit more flexible:

Hive tests passing on at least two implementations.

Two implementations feels to me like the right balance to mark this as complete. And reasoning is:

  • Removing this requirement altogether would be prone to error in our specs/tests. Simply because sometimes the writing of the EIP can lead to multiple interpretations, and these are only surfaced after clients consume the generated tests.
  • Requiring only a single passing implementation is also too few since many times the second implementation brings better confirmation that the specs are correctly implemented.
  • While it’s true that a third or fourth implementation can still uncover issues, the problems discovered at that stage are beyond the EIP at that point, rather they are part of the completion of the fork itself.

cc @fselmo @danceratopz

Copy link
Contributor

@fselmo fselmo Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with "at least two" I think. Are we talking about a full implementation here where we believe the specs are now correct, we have enough tests for coverage, and there are at least two clients passing all of the tests? Or is this still within the development cycle?

It will be the case where specs are implemented, some clients implement it as well, and you start going back and forth on a consensus of what is implemented correctly and what is not. Then you tweak the specs and tests, tweak the client implementations, etc... so...

  • At what point in the process are we here?
  • With late additions to the EIP do we then come back here and uncheck this until it's back to being implemented, etc? I imagine this is how it works but just curious.

Also, if we go with this approach, we should have a section that tracks which clients have implemented it so we can signal this and ideally we should link to the branch in the relevant repos.

- [ ] EIP included in a devnet.

Loading