ethereum/ERCs

Pending tasks for ERC migration

lightclient opened this issue · 21 comments

TODO

  • Repos split
  • Website unified on EIPs repo
  • Activate eip-bot on ERC repo (waiting for token)
  • Replace eip: xxxx in ERC template with ERC
  • Sort out eip-1 vs. erc-1
  • More thorough rewrite of the readme
  • Figure out cross-linking
  • Figure out if any of the other non-core EIPs should be moved over here
  • Remove placeholders in EIPs repo
  • Ensure relative links work as intended
cfries commented

Note: Currently all pull request fail due to the HTML Validator reporting broken links.
See https://github.com/ethereum/ERCs/actions/runs/6657294483/job/18091699250?pr=25

A pull request of an ERC fails even if that ERC does not have broken links, because others still have them. However, correcting them will make it harder to migrate pull request, as this will generate conflicts in the git merge.
Not sure if these is a practical solution: but one could

  • disable the HTML validator for a while, or,
  • create a dummy EIP directory (as part of the validation process maybe) (maybe with files containing rHTML redirects)
  • fix all the links and live with merge conflicts.

@cfries thanks for noting this. We're looking into a solution. I would rather not disable the HTML validator because it is a good forcing function to fix this ASAP. The main interim solution I am considering is to add more logic to the jekyll build script in ethereum/eips to convert ERC -> EIP where necessary. Unfortunately that isn't a great solution because then on the compiled site in many places where the ERC should be referred to as ERC it is referred to as EIP.

The longer term solution is to either i) break the website into a separate repo and make it work correctly for both EIP and ERC or ii) to simply deploy an ERC only jekyll instance. Obviously I prefer ii) because it is much simpler.

cfries commented

@lightclient thanks for the reply. I believe there is kind of "deadlock" because an ERC-X is getting a fail because the links in ERC-Y are wrong. Would it be possible to modify the validation process in such a way that it only checks the consistency of links within a pull request's ERC. This would allow to get the PR through.

I'm hesitant to make any changes to the validation checks until we have our next EIPIP call on wednesday. I have removed HTMLProofer as a required check to merge PRs though.

Since Website is already marked as complete;
On the example of our ERC-6956:
Currently, the EIPs and ERCs are only available via https://eips.ethereum.org/EIPS/eip-6956
Maybe you could add https://eips.ethereum.org/ERCS/erc-6956 to match the new naming scheme? To avoid confusion, also https://eips.ethereum.org/EIPS/eip-6956 should point to the erc-6956.md file from this ERCs repo [not sure if it does already].

Edit, missed the webpage, thx @Edoumou (https://ercs.ethereum.org/ERCS/erc-6956)

CodeSpell
Discovered in https://github.com/ethereum/ERCs/actions/runs/6664676695/job/18112761827?pr=43 ;
A lot of ERCs have spelling issues. I manually corrected mine, the suggestions were all correct. Maybe following all unambiguous suggestions of CodeSpell is an option to resolve this fast for all ERCs?

EIP Walidator
Is running now for 19m 21sec ... Runner fails to pick up the job respectively takes a very long time. This could be related to several people working and pushing simultanously a.t.m.

2023-10-27T08:17:03.6049222Z Requested labels: ubuntu-latest
2023-10-27T08:17:03.6049488Z Job defined at: ethereum/ERCs/.github/workflows/ci.yml@refs/pull/43/merge
2023-10-27T08:17:03.6049574Z Waiting for a runner to pick up this job...
2023-10-27T08:17:03.9988102Z Job is waiting for a hosted runner to come online.
2023-10-27T08:17:08.3452129Z Job is about to start running on the hosted runner: GitHub Actions 9 (hosted)

EIP Walidator Bug 1
After ~29min a runner picked up the job, failed due to quota limit; See #45 ... This happened on the first run of this PR as well (can't find logs anymore)

EIP-Walidator Bug 2
When Walidator runs, it fails in checking the requires in the ERC header, See #46

cfries commented

I try to find out if there are some easy regexp to fix the broken links. One can easily bring the 1800 broken links down to 90.
The remaining issues require a bit more work maybe (crosslinking). See here for an example: #42

https://eips.ethereum.org/ERCS/erc-6956

Hey @tbergmueller. There is already a web page for ERCs. Here is the link that points to your proposal:

https://ercs.ethereum.org/ERCS/erc-5521

Thx @Edoumou , missed that; And thx for crediting me with another proposal :D mine is https://ercs.ethereum.org/ERCS/erc-6956

Thx @Edoumou , missed that; And thx for crediting me with another proposal :D mine is https://ercs.ethereum.org/ERCS/erc-6956

My bad @tbergmueller,

Sure, yours is https://ercs.ethereum.org/ERCS/erc-6956

@tbergmueller the issue with the codespell also appears to be a quota limit that causes codespell to run on the entire repo instead of only changed files. I'm not sure what we can really do to reduce the likelihood of hitting the quota limits. It seems like a somewhat rare issue, but we should monitor to see if it is more common than I am thinking.

@lightclient Thanks, I saw you retried the CodeSpell - Could you please trigger Walidator as well, assuming that quota-limit is not an issue any more?
There is no way for me to retry runs, right? I'd need to push again some changes to the PR?

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

Ok sorry will try to do all as soo n as I can

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

Hey @cfries @lightclient , is this issue solved ? If not, can i contribute?
Any additional context would be appreciated. Thanks!