Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to Hardfork Meta process #1852

Merged
Merged
Changes from 1 commit
Commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.

Always

Just for now

@@ -16,11 +16,29 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista

- Codename: Istanbul
- Activation: TBD
- Included EIPs: TBD

### Included EIPs

- TBD

### Accepted EIPs

- TBD

### Proposed EIPs

- TBD

## Timeline

* 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"
* 2019-07-19 (Fri) soft deadline for major client implementations
* 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet)
* 2019-10-16 (Wed) projected date for mainnet upgrade ("Istanbul")

## References

TBA
- [Core Dev call notes](https://github.com/ethereum/pm/issues/66#issuecomment-450840440) where timeline was proposed and accepted

## Copyright

@@ -18,13 +18,89 @@ Today discussions about hard forks happen at various forums and sometimes in ad-

## Specification

A Meta EIP should be created and merged as a *Draft* as soon as a new hard fork is planned. This EIP should contain:
A Meta EIP should be created and merged as a *Draft* as soon as a new hard fork is planned. The hard fork should be 6 - 9 months after the last hard fork.

This comment has been minimized.

Copy link
@timbeiko

timbeiko Mar 20, 2019

Contributor

Given that there is talk about setting a proper HF schedule in the Berlin meetings in April, does it make sense to remove this line for now and re-add it when there is consensus on the HF lengths? -> The hard fork should be 6 - 9 months after the last hard fork.

This comment has been minimized.

Copy link
@axic

axic Mar 28, 2019

Member

I'd agree it may be premature to add this line. Timelines and scheduling would deserve its own chapter.


This EIP should contain:
- the desired codename of the hard fork,
- list of all the EIPs included in the hard fork and
- activation block number once decided and
- activation block number once decided
- a timeline section
- an EIPs to include section
- the **Requires** header should point to the previous hard fork meta EIP.

The draft shall be updated with summaries of the decisions around the hard fork. It should move in to the `Accepted` state once the changes are frozen (i.e. all referenced EIPs are in the `Accepted` state) and in to the `Final` state once the hard fork has been activated.
The draft shall be updated with summaries of the decisions around the hard fork.

### Timeline

Once a timeline with key dates is agreed upon for other crucial dates. The basic outline of a hardfork timeline should include:
* Hard deadline to accept proposals for this hard fork
* Soft deadline for major client implementations
* Projected date for testnet network upgrade
* Projected date for mainnet upgrade (the activation block number / projected date for this block)

### EIP Inclusion Process

Anyone that wishes to propose a Core EIP for the hard fork should make a PR against the Meta EIP representing the hard fork. The EIP must be published as at least `Draft`. It enters the _Proposed EIPs_ section, along with at least one person who is a point of contact for wanting to include the EIP.

Once the EIP has been accepted by Core Devs, the EIP should be moved to the _Accepted EIPs_ section. If the EIP has major client implementations and no security issues by the timeline date, it is scheduled for inclusion.

This comment has been minimized.

Copy link
@timbeiko

timbeiko Mar 20, 2019

Contributor

it is scheduled for inclusion -> Does this mean that it is moved from the Accepted EIPs section to the Included EIPs one?

the timeline date -> Does this mean the Soft deadline for major client implementations date?


---

The Meta EIP representing the hard fork should move in to the `Accepted` state once the changes are frozen (i.e. all referenced EIPs are in the `Accepted` state) and in to the `Final` state once the hard fork has been activated.

## Template

A template for the [Istanbul Hardfork Meta 1679](https://eips.ethereum.org/EIPS/eip-1679) is included below ([source file on Github](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1679.md)):

```
{% raw %}
---
eip: 1679
title: "Hardfork Meta: Istanbul"
author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)
type: Meta
status: Draft
created: 2019-01-04
requires: 1716
---
## Abstract
This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul.
## Specification
- Codename: Istanbul
- Activation: TBD
### Included EIPs
- TBD
### Accepted EIPs
- TBD
### Proposed EIPs
- TBD
## Timeline
* 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"
* 2019-07-19 (Fri) soft deadline for major client implementations
* 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet)
* 2019-10-16 (Wed) projected date for mainnet upgrade ("Istanbul")
## References
- TBD (e.g. link to Core Dev notes or other references)
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
{% endraw %}
```

## Rationale

ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.