Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Improvements to Hardfork Meta process #1852
Hmmm. This is the Hardfork Meta process, not the EIP acceptance process.
Core EIPs can be Accepted without being deployed. This is about deployment into a Hardfork.
I would also just update EIP-1 to point to 233 for the Hardfork process, because I agree that being able to start with one document is very useful.
But I am not totally opposed to making a Hardfork Process section inside EIP-1 -- but it would be the same content as far as I can tell.
I'm okay with the alternative of specifying a "hardfork meta process" somewhere other than EIP-1, as long as it's referenced from there. I just object to the nightmare scenario of having to scan every single EIP for potential amendments to the process. :)
@timbeiko thanks Tim. I don’t know that CoreDevs care to have the discussion — mentioning it so people come here could be good.
Yeah Accepted vs Included was tough.
I think Accepted is agreed on by CoreDevs — Included is when the hardfork ships.
Also means Accepted could get bumped to next HF.
Or we just remove the Included section completely. What do you think?
I think "Included" could be used to signal that the work has been done by most major clients, and "Accepted" would refer to "agreed to be included by core devs". This helps us know that the implementation work has been done.
So, for example, for Istanbul, after the
Then, when major clients have implemented the EIP, ideally before the
I'm not sure how necessary that is though, and whether the extra process of signalling the work has been done actually solves a problem, but that is how I imagine you could create a clear distinction.
Just a thought, but perhaps we could use
This would mean that all EIPs have the same work flow, but that the definition of the steps for Core vs. Non-Core EIPs would vary, which is already the case for the
referenced this pull request
Mar 27, 2019
Based on the discussion at ECH call, proposing an EIP (WIP) for the "selection process of EIPs to be considered for the HF (metaEIP#)" #1929
This may or may not be applicable for Istanbul Upgrade but could be helpful for future upgrades irrespective of upgrade cycle (6-9 months or 3 months) that is yet to be decided by the core devs.