Migration process

  1. Pause changes to ethereum/eips during migration
  2. Copy repo to ethereum/ercs
  3. Run script to determine all ERCs. Delete from ethereum/eips, retain in ethereum/ercs.
  4. ethereum/eips
    • Replace all ERCs with link to new repo.
    • Setup redirect for all ERCs in Jekyll.
    • Update EIP-1 to remove ERC related content. Add info about the ERCs being in a different repo.
    • eipw configuration to check if ERC category and fail
  5. ethereum/ercs
    • Remove all EIPs.
    • Update EIP-1 to remove EIP related content. Add info about the EIPs being in a different repo.
    • eipw configuration to check if ERC category and fail if not.
    • Update all instances of "EIP" and replace with "ERC", including ERCs folder and eip-xxxx.md
  6. Publish both.
  7. Migrate all open PRs from ethereum/eips that concern ERCs to ethereum/ercs.

Questions

  1. old public links should work or redirect (e.g. ERC-20 which is https://eips.ethereum.org/EIPS/eip-20).
    • if the editors are comfortable adding a GEM to the jekyll dependencies, the PR could be modified to include this config change and [a little extra YAML on each EIP
    • bumblefudge: i'm glad to take a stab at the data-entry aspect of this (adding the YAML to each EIP) but someone more familiar with this jekyll/CI/action config should make (and test!) the config changes
  2. Pending pull requests / issues related to ERCs should be migrated to new repo or should be closed. All on-repo discussion shall preserve.
    • GH allows open PRs and Issues to be transferred! I strongly prefer this as it retains all history and notifies openers. I think the order of operations should be:
      • - reach consensus and finalize this hackmd
        • - it might behoove this group to ALSO merge related EIP-1 PRs like PR#7230 before or in tandem
      • - open new repo(s)
      • - merge PR
      • - test/confirm CI and such on both old and new repos
      • - move issues (so that people notified of the move arrive at new repos/contexts with all systems already go)
  3. determine the numbering rule for ERCs
    • in the short term this will be a spreadsheet where the next sequential number is assigned by an editor. Though this still has issues of number gaming. Alternatively if editors have discretion then there could be a perception of preferential treatment to insiders.
  4. setup a new site for ERCs
    • this is ready to go, as is ercs.ethereum.org - just need to publish the github page
  5. setup Github Action workflow for new repo
    • after fixing the current problems of course! will definitely require new PATs

Reference

Governance Improvement Proposals proposed during the EIP/ERC split discussion, may or may not tie to the split

Select a repo