Create EIPsForHardfork.md

[poojaranjan]

EIPs selection process for Hardfork.

[poojaranjan]

Proposing a formal process of selection of EIPs for hardforks.
Discussion thread opened at Eth Magicians

[bmann]

@poojaranjan this is a duplicate of #1852 -- which is an update to EIP233 rather than creating a new one.

[poojaranjan]

@poojaranjan this is a duplicate of #1852 -- which is an update to EIP233 rather than creating a new one.

@bmann Although this looks similar on the surface there are nuances in PR #1929 that will further refine the process and workflow of EIP submission. This EIP is based on the latest discussion in the Ethereum Cat Herders.

[poojaranjan]

EIP 1929 is basically the extension to EIP 233. Further explained here.

[axic]

Is there any chance to merge this content into 233?

[axic]

Actually it seems you explain the difference well here: ethcatherders/PM#60 (comment)

[axic]

@poojaranjan would you be interested adding the content from here into EIP-233?

[poojaranjan]

@axic I think that would be a good idea to merge the content. Let’s catch up sometime after you’re free from merging of EIPs for 1679 :) Gitter is fine with me, does it work for you?

On Sun, May 19, 2019 at 9:16 PM Alex Beregszaszi ***@***.***> wrote: @poojaranjan <https://github.com/poojaranjan> would you be interested adding the content from here into EIP-233? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1929?email_source=notifications&email_token=AHCOQFOEFNM2DWEPKH3W43LPWH3VZA5CNFSM4HEX6CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVXPEIA#issuecomment-493810208>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHCOQFIV6RG7RS5UT2D37BLPWH3VZANCNFSM4HEX6CAQ> .

-- Pooja Ranjan

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[poojaranjan]

The proposal is updated as per the recent discussions and is available for review.

[MicahZoltu]

This feels like it should live in the Readme for the eth1.0-specs repository, with maybe a one-line passing mention in thds repository's readme (basically just: "go here to discuss hardfork inclusion").

Since hard forks are no longer part of the EIP process, having this be a meta EIP in this repository seems inappropriate.

[poojaranjan]

Since hard forks are no longer part of the EIP process, having this be a meta EIP in this repository seems inappropriate.

Thank you for review @MicahZoltu. But, respectfully, I disagree. I think the change is brought to Standard track Core EIP process and should not affect Meta EIP.

As per the EIP-1 is "A Meta EIP describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP."

It is a good practice adding the text to Readme, but Readme is a document limited to a repository. No one will get to know the process if one couldn't reach the particular GitHub repository.

While Meta EIP describes what is the process and points towards the correct Github repository where we can access the Readme (Instruction to be followed for that repo).

[MicahZoltu]

This comes back to my general distaste for having anything other than technical standards in the EIPs repository, which is contrary to the rules as currently written. I believe you are correct that per the current rules, this is likely appropriate so I'll abstain and let others review this and make a call as to whether we should merge or not.

Interestingly, this is the 2nd or 3rd EIP I have seen in the past couple weeks that isn't a technical specification (people adding stuff to Meta or Informational). I wonder why the sudden increase in non-technical EIPs in the EIPs repository? Maybe it is just a side effect of us getting through the PR backlog?

[poojaranjan]

@MicahZoltu

This comes back to my general distaste for having anything other than technical standards in the EIPs repository, which is contrary to the rules as currently written. I believe you are correct that per the current rules, this is likely appropriate so I'll abstain and let others review this and make a call as to whether we should merge or not.

The (original) proposal when introduced, received good feedbacks from EIP editors @Arachnid @Souptacular and well received by the community.

It was also discussed in the All Core Dev meeting but was shelved (based on my recollection) for some concerns:

• "it risks confusing the EIP standardisation process with network governance, and the perception that EIP editors are the ones who decide what goes into a fork. Other than that, this is a nice step forward in formalising forks."

-> After decoupling the EIP standardization and Network upgrade process, this is addressed.

• "I think documenting the process is super, super helpful! I also think that if there is no change proposed, an EIP isn’t necessary. I think that’s where a lot of the confusion is coming from with regards to this."

-> The updated proposal is a documentation of new changes brought with the new Eth1.0-spec repo dedicated to network upgrade process.

• to be merged with EIP-233

-> @axic suggested adding the content from here into EIP-233, and I (almost) agreed. However, I explained that there are nuances that suggest this proposal to be a stand-alone proposal.

I believe, most of the concerns are now being addressed with this updated proposal that earlier may have stopped from being merged.

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.