This topic is intended be the discussion for EIP-233. Any comment or feedback is very much appreciated!
2 Likes
@axic, how do you think that this would appear in the process outlined in EIP-1?
Perhaps defining a separate EIP such as EIP-233 for actions taken by specified stakeholders in the community is an optimal approach, rather than aggregate all possible actions by non-Editors into EIP-1.
From EIP-1, this section in particular mentions the hard fork process:
Accepted (Core EIPs only) – This EIP is in the hands of the Ethereum client developers. Their process for deciding whether to encode it into their clients as part of a hard fork is not part of the EIP process.
Final – Standards Track Core EIPs must be implemented in at least three viable Ethereum clients before it can be considered Final. When the implementation is complete and adopted by the community, the status will be changed to “Final”.
I don’t think the EIP repo should be used for this, nor should the EIP process be used for this. The EIP process is a standards process. Hard forks are a deployment process. They are fundamentally different and IMO should be kept separate with separate processes.
For an analogy, W3C has a process for coming up with web standards and a place for hosting them and discussing them, but it doesn’t contain process for browser deployment/rollout or how web developers go about adopting new features.
2 Likes
One of these days I’m just going to stake all my opinions with Micah.
BUT — we (with a definition of we needed) need to get better at hard forks. Who what where is that discussed.
Browsers are in competition and don’t need to coordinate to keep the Internet from breaking. In fact, they regularly break portions of it due to individual decisions.
I think client developers can communicate among themselves however they like, including a GitHub repository where people propose things and a process for ratifying those proposals across teams. 
I merely think that co-locating that decision making process with the standards process is not a good idea. I make no claims that the EIP process format shouldn’t be used.
I think EIP-1 is rather complex already and as @MicahZoltu reasons it may be a different process.
I think your reasoning is compelling, but I would say the situation is a bit more complex than that.
The meta “hard fork” EIPs I think are needed, because changes can be very interconnected/interdependent and there must be a way to a place to discuss how can they bundled.
I’m really glad this discussion is back!
Creating a Meta HF EIP document should be a key part of the upgrade process. I would advocate for specifying that it is for a HF rather than just “Meta EIP”, and for using a code in referring to them along the lines of ERCs, e.g. HFM-1013 with the same numbering as EIP-1013.
I was recently looking at how the version of the protocol has advanced over time, and these HFMs were very helpful.
Also related to EIP-233 discussion is this idea I’ve been working on about semantic versioning and release candidates.
Perhaps the HF Meta EIP document could have an event list, referring to all attempts to release the upgrade, and which network this happened on (i.e. 8.0.0-rc1 deployed to Ropsten).
1 Like
I agree that there needs to be a place to coordinate and discuss. I merely argue that we should have a separate place, not the standards repository. I would love it if ETH, ETC, EOS, etc. Could all use this repo for EIPs, and then each had a separate place for discussing which EIPs went into a hard fork, what block it was on, etc.
1 Like
I think the biggest value in a formal hardfork process is a schedule of events.
For a comparison to how another mature community handles this Java recently (2 years ago) went to a rapid release cadence, which for Java is every 6 months instead of every 2-3 years. The rapid release allows for features to slip a release when there is certainty that another release is fairly soon. Key to that is a schedule of dates where a feature must be ready or be dropped. Miss the train when it left the station? No worries another one is coming soon and at a fixed schedule. Java’s strict schedule is based on bugs and severity level - (https://openjdk.java.net/jeps/3). For us I think all features are the same level.
Based on Afri’s previous schedule (EEP-5: Ethereum Hardfork Process - request for collaboration) it would look something like
- T minus 20 weeks / 5 months - hard deadline to accept proposals for “Istanbul”
- T minus 12 weeks / 3 months - Client Implementations Due
- T minus 8 weeks / 2 months- Testnet Network Update
- T - Mainnet Network Update
It would be nice to add a “Finished EIPs for consideration due” at 24 weeks/6 months and “EIPs announce intent” sometime before that (28 weeks / 7 months)? For a notional Oct 2019 launch that would mean that EIPs are due in April and the hard cutoff is May. EIPs trying to get in should announce their intent in March, which is now.
If we do a 9 month cadence we have 2 months of quiet after the hard fork, or room to move the hard fork out if needed. At 6 months we would have an overlapping period between client implementations due and the network update.
This would give a deadline for the drivers of the EIPs to get ready for the hard fork and would provide certainty as to whether or not EIPs are going to be in the fork or not based on an impartial schedule.
1 Like
I made a PR finally @axic – feel free to edit https://github.com/ethereum/EIPs/pull/1852
Main two changes:
(1) Embed a timeline in the EIP
(2) Proposed EIPs need to get PR’d into the Hardfork Meta EIP
I embedded a template and I also updated Istanbul to follow the format.
1 Like
This is now merged. We can make a call for EIPs that want to be included in Istanbul to do PRs.