Might be a good time to move this EIP to Living status rather than Last Call
1 Like
My preference is for it to be final.
If/when we change network upgrade inclusion stages, then we just create a new Meta EIP.
2 Likes
Reiterating my GitHub comment for consideration before this EIP is moved to a different status.
With due respect, before debating the “EIP status”, I would argue that the EIP itself is confusing in its current form.
The Motivation states: “This EIP proposes definitions for the various stages EIPs go through when planning network upgrades.”
However, throughout the document, the term “status” is used interchangeably with “stage”, which creates ambiguity.
To be clear:
- EIP status refers to the standardization and review lifecycle of an EIP.
- EIP stages refer to the network upgrade planning and deployment process.
These are two distinct concepts, and conflating them risks long-term confusion, especially for new contributors and readers of the specification.
This may have been missed earlier, but it can still be corrected. There is an open PR addressing this inconsistency. I would request the authors to review it and either merge it if appropriate, or explicitly explain the rationale for rejecting it.
The purpose of progressing through EIP statuses is to enable review and convergence. A clear response from the authors, whether to accept or close earlier PR before responding to this change, would help keep the process moving forward.
As discussed during ACDC #182, here is the PR to clarify the DFI process for handling EIP lists during the status change of Upgrade Meta.
Upon further consideration, I believe the Proposed for Inclusion list should also be removed when the Upgrade Meta EIP is promoted to Review status, and this behavior should be explicitly documented. I’ve therefore updated the PR to include this change.
Please refer to the discussion here for additional context. For convenience, I’ve also included my rationale for removing the Proposed for Inclusion list below.
Why should Proposed for Inclusion be removed when the Upgrade Meta EIP is promoted to Review?
Ideally, an Upgrade Meta EIP should only be promoted to Review once all EIPs referenced in the proposal - regardless of their Upgrade Stage have reached at least Review status. In practice, by this point all candidate EIPs will already be undergoing testing on either EIP or upgrade devnets, meaning the window for proposing additional EIPs has effectively closed. As a result, the Proposed for Inclusion list no longer serves a meaningful purpose and instead becomes a blocker to promoting the Meta EIP.
Additionally, similar to Declined for Inclusion, there is a high likelihood that the Proposed for Inclusion list will contain at least one EIP that is still in Draft status. Since the repository bot prevents a Meta EIP from being merged while it references a `Draft’ EIP, these entries must be removed before the Meta EIP can progress.
For these reasons, I propose removing both the Proposed for Inclusion and Declined for Inclusion lists when the Upgrade Meta EIP is promoted to Review, leaving only the sections that remain relevant for the rest of the upgrade lifecycle.
The specification changes are reflected in the same PR.