-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Move ERCs to separate repository #7206
Conversation
EIP Review Bot is running... |
The commit 4b4335e (as a parent of 36ddc29) contains errors. |
I like 👍 |
This is sorely needed for organizations sake, and to make application development more clear and accessible to developers who want to build on ethereum, and no longer need to work intimately with core consensus parts of it. The reality is, ethereum is much easier to build apps on now than it was when this EIP system was made, and the dev tool ecosystem has been growing exponentially for years. The seperation makes complete sense. Running a simple script like that is a good way to kick things off. We can make new templates for the distinct repos as a new proposal afterwards. Let's get this in. |
The PR is making it sound like "oh because ERC and Core EIPs are in the same repo we can't make better editorial policy", and hence the proposal to split. The actual problem is that the current EIP editorial policy are more made from the perspective by some editors, and we lack author voice in the process. And there are many restriction we want to relax, for both Core and other EIPs. I know many ERC authors I talk to are unhappy with EIP restrictions. Don't that also apply to Execution and Consensus devs?
According to my debate with @lightclient on EIP Editor Channel of Discord, his policy stance is that he doesn't want the EIP editorial policy to relax for Core EIPs. Will you still support the splitting if you know the intent for splitting is so that the policy for Core EIP could remain the same? How does it solve the problem? My question for Consensus Devs and perspective EIP authors: My question to @lightclient: what's your policy solution to "Consensus Layer is also utilizing the EIP process"? Are they unhappy because the policy is too "relaxed" instead? I must voice I strong opposition to this PR.
|
I don't have the energy to fight you or the other opposing editors anymore. Every minute change takes months or years of argument. I am confident that with the separation, the processes can evolve more fluidly. Until then, everyone will remain disengaged because their time is better spent elsewhere. |
EIPs should be easy to create & update for core devs. Unfortunately it is not. The best worst option to quickly improve the situation for core devs is splitting, so I (as a non editor) am in favor of just getting on with it now. |
@abcoathup I agree with your intention but the proposer of this PR is actually trying to split so he could keep the policy strict and hard for core dev, the opposite to your reason supporting the split. Check my comment above for details. |
The separation makes sense as it reduces noise and helps standardize the approval process, which MUST be different. However, a subtle yet important point is that some ERCs serve as a proof-of-concept for a future EIP. This means these ERCs should get core developers' "eyeballs" (feedback) as soon as possible to avoid unnecessary development cycles. So a general +1 for the direction, but we need to understand that the 2 repos will be tightly coupled and offer a solution. (Naive solution would be a PR tag in the new repo). |
@xinbenlv from a different angle, does splitting out the ERCs make things worse than they are right now for Core EIPs? If I'm understanding your position correctly (no guarantees), your point seems to be that the editorial process for Core also needs to be updated, but even if that is the case, is it a reason to prevent splitting off the ERCs? A side note about ordering: this is likely obvious, but a number of ERCs are known widely by number, in particular the token ERCs (20, 721, 1155). I hope this isn't only my opinion, but my opinion is that no matter what numbering scheme is implemented for ERCs (assuming they're split off), these numbers should be reserved for these ERCs. There are other ERCs where I could see this being the case (165, 1167 as examples) too. Thanks for getting this moving @lightclient ! |
I have voiced my strong support for this proposal in the past multiple times. |
@xinbenlv according to core devs the status quo isn't working. The process needs to fit the needs of its users. ERCs and EIPs are very different beasts, they operate at different layers and have different users. ERCs are noisy and lead to a noisy repo. The noise can act as a barrier to being involved in core EIPs. If EIPs need strict linking rules, and ERCs want broader linking rules, then this is an example of where trying to keep EIPs and ERCs in the one repo under the same rules impacts both. I've been checking the repo most week days for the last two years. Keeping ERCs and EIPs in the same repo hasn't led to massive improvements for EIPs, so it is time to do something different. I don't want to be sat here in two years time and we haven't made progress. So my vote is for change. |
"Split to let Core focus" is a reasonable rationale, but if core EIPs want a different repo to focus, what do you think about Network and Interface EIPs? Should they stay with Core or Stay with ERCs? What if consensu just wanna look at consensus exe just wanna look at exe? Shall there be further split? The eips.ethereum.org site has listed Core EIP by its category, there are also RSS feed by category, and github PR are categorized by type. If Core wants engage, there are tools to do so. I feel the real problem blocking core devs and many other is still the EIP process is very daunting for them to even beging to edit / author, and this split doesn't help. We really need to fix the EIP process. |
Thank you for your response @abcoathup
Earlier you cited @michaelsproul 's tweet as a supporting evidence for the process being hard for Core Devs. Yet I think the proposal to split intend to keep it hard for Core Devs
The differences apply to Interface and Network EIPs and likely also exist between Consensus and Execution layers to some extend.
It seems at least in @michaelsproul 's case, he was complaining about link policy too strict. I have not hear many complaints by core dev that "authoring EIP is too easy", or "the restriction is too loose". Rather, everyone complaint I hear from core authors or other are the process being too restrictive.
4337 was an ERC attempt over two unsuccessful prior attempts to achive AA at Core level. Does it count as as an example that different level discussion benefit the Ethereum ecosystem?
Yes we really need to change, and really need to make process. But splitting which doens't make any policy improvment in thr first place, |
For full context. Similar proposal has been also discussed in FEM https://ethereum-magicians.org/t/proposal-forking-ercs-from-eips-repository/12804/6 |
Agreed, @wschwab. I don't think any existing number would be changed (ERC-20 would remain ERC-20). We'd just need to figure out a scheme to number future EIPs/ERCs |
A problem is that, yes, overlapping use of ERC and EIP have have caused confusion for a long time now. Going forward the confusion could remain for a long time. Numbering schemes can't help that. |
As an editor I am currently blocking consensus on this change and will not approve merging this PR. I've rgued why in many places recently and many times over the yeas. |
Per ACD #164, we're going to move forward with this. We'll discuss more of the specifics on EIPIP next week. |
Thanks for discussing this with CoreDevs. Personally I will respect consensus of the community. I will try to collect feedback from ERC authors on next AllERCDevs which is happening on next Thursday. If there is no objection from ERC authors, I will not attempt to block it on my side. Can we hold the discussion on EIPIP until after the AllERCDevs? |
I think you should seek out ERC authors who disapprove of this before EIPIP next week. |
The AllERCDevs time runs regularly, so I would appreciate there is a chance to speak in a live meeting so more people are aware of. Also, I've asked in the channel of AllWalletDevs to see if they have any opinion or not. |
No, we are not. The Core Devs do not control the EIP organization and process. The core devs had at most a day or so of warning to discuss a contentious decision that is not theirs to make. I learned very little in that meeting as to what their pain points actually are, just that given a single proposal that purports to fix them they approved. So I am still blocking consensus. We need to fix problems, but absent a fairly complete plan as to what needs fixing and how splitting repos will actually help and not harm my objections remain unanswered. Blocking consensus means that if I cannot be convinced to support or at least acquiesce I will resign. |
I cannot speak to the procedural best step forward, but my read on the situation is that: 1.) Most people tend to agree that CORE and higher-level/EIP discussion have slightly different process needs and fairly distinct communities/inputs/fora they respond to. However tightly or loosely coupled, however many editors they have in common, most seem to agree that separating them will improve the quality-of-life and signal-to-noise ratio for people only interested in, or confident speaking up about, one of the two sides of the coin. For example, as a veteran of app-level/EIP-level companies, and organizer of the CAIP process at CASA, I can say that if the process split in two, I would volunteer to be a committed/every-PR editor of a segregated EIP process, and would prefer a "weekly digest/overview" of CORE issues, which honestly I'm not qualified to speak on. 2.) 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. I think the question of how the EIP process or the CORE process is "stricter" or more editorially involved kind of presumes two different bodies of editors committing to more or less editorial power and responsibility... so bifurcating the process might be trading ONE can of worms for TWO, even if it also activates a broader pool of willing editors like myself to clean up the two messes separately 😅 3.) Would objectors prefer... |
As my commitment to my own principle of "I'll follow the consensus despite I might hold minority view.", I put together a list of task items i think could be used as a starting point of discussing "How to split": Task list for ERC/EIP Split. Please feel free to edit. |
Because I have absolutely no chill, I jumped in and annotated this to-do list. If this is overstepping my role as a pro-active rando, feel free to ignore my annotations, throw out half of them, edit them unrecognizably etc before during or after today's call. But I thought it might be a net-positive contribution to the efficiency of today's call-time to put the low-hanging fruit on paper and get us to a gameplan sooner. Thanks to everyone who's put in so much time and thought so far. |
Could you explain? |
EDIT, see below. |
Very interesting conversation. Personally, as an ERC author, I found the process frustrating slow. If that can be improved with a split, the split is very welcome. |
I do think some sort of split of the repos is necessary. |
I've decided that the way of splitting things that I'd prefer can be achieved easily enough after this PR -- should further splitting be desired. So far as I can tell this PR only moves files and does not affect how the Editors organize themselves. If so, I have no objections to merging it. |
LGTM |
This comment was marked as spam.
This comment was marked as spam.
* Fix EIP-Bot CI * Add newline to CODEOWNERS * Make changes for testing * Test if GH Actions is a valid codeowner * It isn't allowed * Fix infinite loop * Do some tricks to avoid unneccesary extra runs * Fixing bug * Add Pandapip1-bot * Fix quotes * Another fix bites the dust * Another fix * Another thing * Use my testing fork * More fixes * Unpin while in dev * Add testing bot to codeowners * Is that the bug? * Try this fix * Quickfix * That was an easy fix * Remove Pandapip1-bot references * Update diff * Missed some * Pin to commit
eip: 173 | ||
title: Contract Ownership Standard | ||
description: A standard interface for ownership of contracts | ||
author: Nick Mudge (@mudgen), Dan Finlay <dan@danfinlay.com> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx
Long ago when the EIPs repository was created, there was a vision of a single home for all standards related to Ethereum. The community was small and most people were interacting at every level of the stack. It made sense to combine application standards with core consensus changes.
Since then, the ecosystem has grown. Today, the chasm between application development and core development is wide. Less people are involved across the stack (for better or worse); yet the repository remains unified.
For years, we've considered separating the repository. This would allow ERC and EIP processes to evolve more naturally due to the independence. But it's always difficult to reach critical threshold to make a change like this happen. Each time we get lost in the details of the migration and the debate grinds progress to a halt.
Now that the Consensus Layer is also utilizing the EIP process, the cracks are becoming more visible. There are changes we could make to the process that might benefit them more, but because we also need to ensure the quality of ERCs, we are restricted.
There are also many more efforts to catalyze applications around the ERC process. Attempts have been made to develop working groups and review groups for certain ERC "categories" (a distinction that doesn't even technically exist because of the unified repo).
Ultimately, I believe it is finally time to separate these processes.
--
Proposal
I propose the following steps are taken to perform the separation:
ercs.ethereum.org
subdomain and update the CI to point to the ERCs repo.eips.ethereum.org
to go to the new website.This is the bare minimum to separate the processes. There will then be a longer tail of changes that need to be made to remove references no longer make sense, update the website templates to not include categories that don't exist, etc.
I don't want to get bogged down with endless debate about every single faucet of the migration. If the migration is supported in the first place, we should make it happen even if it takes a bit of time to polish. If we wait for perfection, we will never be able to change.
Script