Okay, here is the solution to everyone’s issues:
And a full narrated YouTube explaining it: New EIPs homepage PR 6483 - YouTube
Don’t have time to click that button? Here is a gif, you’re already watching it…
3 Likes
The biggest reason to split the repositories is that it will make it easier for the processes to diverge, both in governance and technical stuff (like CI.) Sure, we can have the processes diverge in the same repository, but it makes the tooling simpler if we also split the repositories.
1 Like
Our bots do add tags to the PRs to make them easier to search (eg. Core Only) but I do very much see your point here.
2 Likes
FYI - you can filter PRs easily. For example, to view only new Core EIPs, you can use:
https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ac-new+label%3At-core
EDIT: Wow, I missed sam’s comment above. Great minds think alike, I guess.
1 Like
A meta-comment on these recurring split-the-repo discussions:
My old psychology mentor had a (tautological) maxim: “If a situation calls for a person to do something they can’t do then they will do something they can do, if they do anything at all.”
It seems to me that we have social problems that we don’t know how to solve, so we are trying to solve technical problems instead.
3 Likes
Come to a decision.
Fork it!
1 Like
I think you brought this up in the last EIPIP meeting, @Pandapip1. For core EIPs the original concept of Final really was running on the mainnet. Up until then the specification must be open to change – otherwise what is deployed might intentionally not match the Final spec.
Just because that was the original thought doesn’t mean that the process can’t change to support a competing idea, especially if circumstances have changed. The Ethereum mainnet is weakly subjective now, and we have stated as a goal that we want to remove as many subjective traces as possible from the EIP process!
I guess it doesn’t matter that much when we call it Final, because it rarely happens that the behavior of what is deployed is different than specified. If it is, then that can be handled with an Errata
I am 100% for splitting the repository, on the condition that the ERC repo can facilitate external links or require some code to be included i. The proposals.
The main issue with ERCs – there is not a formal way to describe the interface for contracts. Have a standard repo –– this will lead to a canonical ABI definition –– can have semantic rules around this. Can run some specific unit tests against this, etc.
Some clear principles or rules governing what basic terms/definitions are for included code, eg:
(this is an example, not an accurate representation/definition!)
Abstract ABI: a generated contract ABI interface; as described in the ABI generated artifact; is called an ABI definition. Each ABI definition has an associated ABI identifier; e.g. constant, inputs, outputs, stateMutability, payable, type, name (which may be implicit in the case of Contract).
Instead of “Final” how about: conclusive? Additionally a state that can communicate that this relevant EIP/ERC is no longer valid/useful or has been replaced would be “Moribund”
After years of these discussions, I remain 100% opposed to splitting the repos..
1 Like
Fwiw I think splitting the repos would have the w benefit of making package management for smart contracts more viable. If the ERC repo has some constraints, it could be much more easily adopted by developers seeing that its being supported.
2 Likes
We discussed this on ACDE164 and client devs were strongly in favour. We agreed to discuss how to move this forward on the next EIPIP call.
2 Likes
Putting here a few examples where ERC / Core EIP will benefit knowledge from each other.
-
ERC-4337 as consideration for create2 shadowing in driving precompile adoption Add EIP: Precompiled for secp256r1 Curve Support by ulerdogan · Pull Request #7212 · ethereum/EIPs · GitHub
-
ERC-2098 as inspiration for deciding design about
vcomponent in verification. https://github.com/ethereum/EIPs/pull/7212#discussion_r1240413986
3 Likes
@shemnon We are at the end of Last Call, and as a Meta proposal I have no big problems with this – moving this EIP to Final doesn’t necessarily mean we merge Move ERCs to separate repository by lightclient · Pull Request #7206 · ethereum/EIPs · GitHub, and it lays out that proposal well. Thanks.
I think our fundamental disagreement starts here:
For years, we’ve considered separating the repository. This would allow ERC and EIP processes to evolve more naturally due to the independence.
Although you speak of repositories and processes, the deeper issues are around people and governance. In particular, does splitting the repositories mean splitting the Editors into separate organizations? It’s your proposal, so I’m not asking you to change your intent. However,
If you intend to split the Editors into two organizations you should be explicit. This is the only change I really want to see before this goes to Final.
It is of course the organizational split that I most object to.
I think the most insightful comment on this is from @bumblefudge here. In part:
But notice the subtle slide from “split the repos” to “split the editorial processes into two separate deciding bodies with different processes.” I think the pushback comes from the distance between those two changes. This PR only splits the repos, with a sort of implicit promise that the processes can evolve separately down the road, and if I’m reading correctly the objections, it’s the uncertainty of this future step that is giving people pause, and/or the “overpromising” that severing the process helps both halves work better in the near future … bifurcating the process might be trading ONE can of worms for TWO …
I do think there are some misunderstandings of the Pain relief work in progress that might be worth correcting. In particular, you write:
While working groups are excellent for the ERC community, it is overhead for the core protocol community that would only add friction to an already established process with known governance checkpoints.
I am trying to reduce overhead by saying that the Core Developers are already a de facto working group. And I’ve said in a few places that I’m trying to reduce the friction by getting the Editors “out of the workflow business”. A working group itself defines it own governance and the stages of its own processes. So I’ve proposed a separate working-group-status header to use for those governance checkpoints. (We could allow working groups to use the existing Status header instead.)
As I wrote here:
I’m proposing that once an EIP is a Draft the Core Developers will have full control – in the sense that the EIP need not meet Editorial standards again until it goes to Final, which can happen after the upgrade. And the standards for Draft should be reasonably low. That way the Editors should never be in the position of blocking an upgrade.
And I’m slightly off on not meeting Editorial standards – minimal standards on format are needed to be sure the draft renders OK on https://eips.ethereum.org.
You insisted I write an EIP but I resisted on the premise that it would be meaningless and you would move the goalposts in the end. That just happened
It’s Tim’s and lightclient’s proposal, which I fully support. I’m being a functionary in conforming to your process needs.
But splitting the org has always been part of the proposal. From the top of this very thread…
Editors will be grandfathered in to both repos, processes can evolve independently. Was there specific wording you want to see? Please propose it so I can get it right in one pass.
It’s not a shift. It’s literally in the tl;dr from the very beginning. Separate independent processes.
Then what do the editors do? Seriously, what EIP work have you done outside of governance and workflow debates since January? Editors who are not editing EIPs are not really editing. Perhaps we need to rename them “reviewers” to make it clear the work we do need from them.
1 Like
Moving files doesn’t change anything about how persons organize themselves. I don’t object to moving the files. I object to splitting up the Editors into separate organizations. I’m leaving it to the other Editors to decide whether they want to do that.
The original proposal was to both split org and repo. That you are willing to accept half of it does not change the original intent of the proposal.
1 Like
I do not question your intent, Danno. My only ask is that you be more explicit from the start:
Abstract
Describes the motivation and rational for splitting the EIP process into an EIP Process, targeting core ethereum changes and an ERC process, targeting application layer specifications.
Processes can also evolve within an organization. Your intent is to split the Editors into two independent organizations, so please say so here. That’s all.
1 Like