Currently, the EIP bot will block an EIP moving from Draft to Review if any EIP linked is in a Draft or Stagnant stage. While this is reasonable for EIPs that are strict dependencies, listed in the requires header field, it feels overly restrictive when applied to EIPs that are simply mentioned as references in the body of an EIP.
For these, we should consider allowing links to specific commits in the EIPs repo, like we do for the EL and CL pyspecs.
Here are recent examples where the current behaviour is problematic:
EIP-2935 cannot be moved to Review because it has the line: Very similar ideas were proposed before in [EIP-210](./eip-210.md) et al. and EIP-210 is stagnant (https://github.com/ethereum/EIPs/pull/8652). It's unrealistic to expect authors of years-old EIPs to update the status on their proposal in order for a newer one to move forward in the process. Allowing the author to link to this would solve the issue.
Similarly, EIP-7702 cannot be moved to Review because it references EIP-5003 as follows: Once this is implemented, [EIP-5003](./eip-5003.md) is "only one line of code": just add a flag to not set the code back to empty at the end.. In this case, where 5003 is also under active development, allowing the authors of 7702 to reference a specific commit of 5003 helps ensure the spec is coherent. In the case where 5003 changes substantially and is no longer a "one line change" after 7702, readers can see that the reference is to an older version of the spec.
On that last point, using internal links for requires EIP mentions and external links for other mentions will help readers differentiate between the two when clicking the links.
Currently, the EIP bot will block an EIP moving from
DrafttoReviewif any EIP linked is in aDraftorStagnantstage. While this is reasonable for EIPs that are strict dependencies, listed in therequiresheader field, it feels overly restrictive when applied to EIPs that are simply mentioned as references in the body of an EIP.For these, we should consider allowing links to specific commits in the EIPs repo, like we do for the EL and CL pyspecs.
Here are recent examples where the current behaviour is problematic:
Reviewbecause it has the line:Very similar ideas were proposed before in [EIP-210](./eip-210.md) et al.and EIP-210 is stagnant (https://github.com/ethereum/EIPs/pull/8652). It's unrealistic to expect authors of years-old EIPs to update the status on their proposal in order for a newer one to move forward in the process. Allowing the author to link to this would solve the issue.Reviewbecause it references EIP-5003 as follows:Once this is implemented, [EIP-5003](./eip-5003.md) is "only one line of code": just add a flag to not set the code back to empty at the end.. In this case, where 5003 is also under active development, allowing the authors of 7702 to reference a specific commit of 5003 helps ensure the spec is coherent. In the case where 5003 changes substantially and is no longer a "one line change" after 7702, readers can see that the reference is to an older version of the spec.On that last point, using internal links for
requiresEIP mentions and external links for other mentions will help readers differentiate between the two when clicking the links.