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

Conversation

Projects
None yet
6 participants
@bmann
Copy link
Contributor

commented Mar 19, 2019

@axic I've made some proposed changes to 233 and updated 1679 to match.

Doesn't look very controversial, just embeds timeline and also includes sections for Proposed / Accepted / Included EIPs.

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Mar 19, 2019

233 needs to be proposed as amendments to EIP-1. Amending the EIP process by writing new EIPs doesn't work; it would make it next to impossible for anyone to figure out what the current set of rules for the EIP process are.

CC @axic

@bmann

This comment has been minimized.

Copy link
Contributor Author

commented Mar 19, 2019

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.

@Arachnid

This comment has been minimized.

Copy link
Collaborator

commented Mar 19, 2019

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. :)

@@ -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.

@eip-automerger

This comment has been minimized.

Copy link
Collaborator

commented Mar 20, 2019

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

  • EIP 1679 requires approval from one of (@5chdn, @axic)
  • EIP 233 requires approval from one of (@axic)

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?

@timbeiko

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

Left some small comments. It's a bit unclear to me what the distinction between "Accepted" and "Included" means.

@timbeiko

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

Should this be discussed as part of the EIPs agenda item in the next core devs call? ethereum/pm#89 (comment)

@bmann

This comment has been minimized.

Copy link
Contributor Author

commented Mar 21, 2019

@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?

@timbeiko

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2019

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 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul" the EIPs for the HF should all be in Accepted, and anything that isn't won't be part of the implementation for Istanbul.

Then, when major clients have implemented the EIP, ideally before the 2019-07-19 (Fri) soft deadline for major client implementations, they move to "Included".

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.

@timbeiko

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

Just a thought, but perhaps we could use Final instead of Included to be consistent with terminology in EIP-1.

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 Accepted step.

@axic

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

I think I like the general direction. My only comment is on the "6 - 9 months".

Can we remove that? Also once removed, anybody objects merging this and continuing the discussion on the "discussions-to" link? :)

@bmann

This comment has been minimized.

Copy link
Contributor Author

commented Mar 28, 2019

Yeah you’re right — the 6 - 9 months doesn’t make sense baked in here. I was thinking to specify as much as possible, but likely people will make new hardfork meta by copying the template anyway.

@poojaranjan

This comment has been minimized.

Copy link

commented Apr 10, 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.

@axic

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

@bmann can you remove the 6-9 months sentence so we can merge this?

@bmann

This comment has been minimized.

Copy link
Contributor Author

commented Apr 12, 2019

@axic done!

@Arachnid do you have concerns about this process?

@axic

axic approved these changes Apr 23, 2019

@eip-automerger eip-automerger merged commit 9577bb7 into ethereum:master Apr 23, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bmann

This comment has been minimized.

Copy link
Contributor Author

commented Apr 23, 2019

@axic maybe a good place to list champions too

@expede expede deleted the spadebuilders:eip233-hardfork-meta-updates branch Apr 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.