Revert EIP-191 to review #3572
Revert EIP-191 to review #3572
Conversation
|
For these extremely ancient EIPs that got forgotten in Last Call, I think I would rather just merge them to final than trying to fix them. There are a ton of old EIPs that are not well formed even Final ones, and we have not had the manpower to go back and bring them all up to modern standards. In the case where Last Call ended years ago, I would prefer to just treat them the same as we do Final EIPs since it just feels like a bureaucratic formality to make the author's dig back in to history like this. |
|
@MicahZoltu I understand you are trying to get this done here. So I have gone through all those open Last Calls and provided my feedback. Summary: Most of them should be removed from Last Call back to Draft/Last Call based on identified reasons. One of them is basically done, just missing a note about an implementation. https://eips.ethereum.org/EIPS/eip-173Feedback at #173 https://eips.ethereum.org/EIPS/eip-191
https://eips.ethereum.org/EIPS/eip-234
https://eips.ethereum.org/EIPS/eip-778
https://eips.ethereum.org/EIPS/eip-868Notes left at ethereum/devp2p#44 (comment) It looks like this is implemented, please reference in the EIP and this should be merged as Final. https://eips.ethereum.org/EIPS/eip-1191Notes left at #1121 (comment) The EIP that endered Last Call was fatally defective and must be reverted to Draft/Review before further consideration. https://eips.ethereum.org/EIPS/eip-2124Notes left at: #2125 (comment) I believe this is a disqualifier and should be reverted to Review before continuing https://eips.ethereum.org/EIPS/eip-2266Notes left at #2266 (comment) I believe MAY be disqualifiers and this should be reverted to Review. https://eips.ethereum.org/EIPS/eip-3338Notes left at https://ethereum-magicians.org/t/eip-2681-limit-account-nonce-to-2-64-1/4324/24?u=fulldecent I believe this is a disqualifier and should be reverted to Review before continuing |
@fulldecent I understand that The Rules Must Be Followed, but I agree with Micah - this seems like pointless bureaucracy. This EIP is over four years old, and is referenced in multiple other standards. I don't see what purpose is served by requiring it to adhere to modern EIP standards; it would more usefully be grandfathered in as a legacy EIP. |
|
I agree with @Arachnid |
|
@fulldecent I think the requirement to keep all implementation links in EIPs up-to-date is not necessary. The idea behind the implementation links is showing that the EIP can be implemented at all. I'm also a bit annoyed by your sudden urge to revert long-implemented and deployed networking EIPs back to Draft status for formal reasons. These EIPs have been incorporated into specifications, they are implemented in clients, and we have verified interop in cross-client test scenarios on hive. Before they got moved to Last Call, these EIPs spent years sitting in Draft state. Regardless of their formal state in the EIP process, these EIPs are effectively final, and will not be changed anymore. |
More about this: the links to implementations are mostly relevant during the review phase of the EIP. At least in go-ethereum, the way we always did it is: we created the prototype implementation and wrote the EIP at the same time. The link in the EIP would typically go to the PR or branch implementing the prototype. We would then bring up the EIP in ACD calls and people could click through to the PR from the EIP to evaluate how much effort it might take to implement it. Once the EIP implementation is merged, the corresponding code may move or be restructured at any time. Also, if an EIP is superseded or enhanced by another change, the links will lose their meaning. |
|
I'd agree with @MicahZoltu @Arachnid @holiman @fjl. Unfortunately, I do not see value in moving a legacy EIP from "Draft" or "Last call" to "Review" to adhere to the present EIP standardization process, unless there is a strong argument for disagreement with that proposal being a standard. However, @fulldecent, I appreciate your effort to review proposals to move EIPs to the correct status. According to proposals listed on eips.ethereum.org, 242/361 EIPs are still in "Draft". We could use your help decreasing the number of "Draft" EIPs. Having a list of proposals that need to be moved forward and those that should be "Withdrawn" (removed) from eips.ethereum.org will be useful or even better if you create PRs to request status change for long-gone proposals. |
|
Echoing others -- I think we need to just make these very old EIPs final. We don't have the resources to ensure perfect formatting on every old EIP, but many of them are used everyday in production. Their status should be representative of that. |
|
Closing since two editors have vetoed. |
|
I am happy with the discussion and decision for this EIP. For the others, we should not merge them just because they are old. We should merge them because they are good and worth publishing. That includes proper review, and referencing two implementations that actually work. We should treat Ethereum as a project that is managing trillions of dollars of assets and worth testing things and having a decent process. Why am I still finding technical errors in Yellow Paper? By instilling an expectation of quality into EIPs we can avoid further errors getting inside and encourage new EIP authors to take the time to check their work before. In the forest we ask people not to start fires. I know YOU are responsible adults and you wouldn't write an EIP that can't be implemented. But the kids watch you and start fires they can't control. So please follow the process. The kids are watching. @poojaranjan Thank you for the invitation. I am not interested in draft EIPs. Those are all people that wanted to do something, so I would be more interested in mentoring them to achieve what they started to do than to shut them down. EF is not sponsoring me any more, and my clients don't need that done, it is not a priority for me. |
Because it does not have a Discussions-To URL