One place that is the "Head" of the process that shows active work. People would go here to see the latest state of active EIPs.
A second being a complete Log of the history all Eips. People would go here to investigate the history of a single EIPs.
The latter would be a lot of information that I don't think should be included in the former. And it gives justification to have two different workflows.
Not specificaly Berlin, or for any targeted fork.
@MadeofTin So, to be clear, EIP 2070 is still the Meta to be followed for Berlin. However, it needs to be updated. Also, EIP 2378 is to be treated as a progressing list. If any of the EIP listed in 2378 gets included in any upgrade, "Pipeline status" will be updated and we will consider the rest of the EIPs for a subsequent upgrade.
Certainly any EIP included in the Berlin meta would come from this list.
One more question, since EIP 2378 lists Core EIPs only; any Non-Core EIPs will never be seen here, even if they are actually being considered for an upgrade. eg, for EIPs for Berlin meta = EIPs from EIP 2378 + Non-core EIPs accepted by ACD. Is my assumption correct?
any Non-Core EIPs will never be seen here, even if they are actually being considered for an upgrade.
Yes, they won't be seen here. This is only for EIPs that have to go through the EIP-centric Fork Model. Meta, Networking, etc... would not join this list. Other types of EIPs will eventually need their own systems and processes for adoption and approval
I am not sure I understand what you mean by using a File as opposed to an EIP. You mean something outside of the current governance system? I am all for better ways of doing things. Can you explain more of what you mean here? @poojaranjan
Maybe because an EIP is essentially a protocol for improvement in Ethereum, which is created to undergo an upgrade
As far as this goes the waters are already pretty muddy. As Core-EIPs (requiring a hardfork), Core-Networking-EIPs (note requiring a Hardfork, but clients need to implement them), ERCs, and other Meta EIPs already use the same processes.
The bigger question would be of governance. EIP Editors and the AllCoreDev calls are all that we have to work with. I personally do not want to and do not think I am qualified to be an EIP editor but to have credentials to maintain the list directly in the case it was a file I would need to be.
This also might be something that could Exist on Ethereum/PM with an EIP used to ratify the list.
I am not sure I understand what you mean by using a File as opposed to an EIP. You mean something outside of the current governance system? I am all for better ways of doing things. Can you explain more of what you mean here? @poojaranjan
Apologies for the confusion. I am not opposed to an EIP in general or suggesting anything outside of the current governance system. My suggestion for creating a file was specific for tracking EIPs 'eligible for inclusion'.
- anyone can make a PR to update an existing file on GitHub, once the tracker is created
- no one necessarily needs to have the access to merge the PR or to be an EIP editor. So, it wouldn't matter which GitHub is decided to store 'eligible for inclusion' tracker.
About the current situation of EIP repo, I want to update you that Cat Herders are now in touch with EIP editors to help with the cleanup. Hopefully, we will manage to have a good working relationship with EIP Editors to avoid delay.
I would love to be a part of this conversation as improving the EIP process is part of what needs to happen for Ethereum to have more effective upgrade plans.
parity --chain foundation.json
