manually backfill eip status history

[dionysuzx]

Description

This PR manually backfills EIP status history. It backfills history so that we have the complete history from ACDE 223 to now. This is when we started to get the inclusion status process in place for Glamsterdam.

How to review this PR

You can review that we have complete history by comparing the Forkcast calls against the individual commits, using the table below. EIP-7805 (FOCIL) is included in the acdc/171 commit, but had history across acdc/170 and acdc/171. You can also check the git history on main if needed for additional context.

Call	Commit
acdc/171	8837996
acdc/170	eec4467
acdc/169	a793a31
acdc/168	no status changes
acde/226	already on main
acde/225	a895446
acde/224	no status changes
acde/223	e13367e

Each commit describes the call it adds status history for. There is one exception which is EIP-7999, which was given a withdrawn status here. It does not appear to have happened in a call, and may have happened offline.

EIP-7805 (FOCIL) was a tricky one to piece together accurately, but should be correct based on the call history. Please review the proposed FOCIL status history.

The remaining two commits from activate pectra page d2278fe and scheduled -> included from fusaka activation should be self-explanatory by the commit message.

[dionysuzx]

Observations that came to mind when implementing this PR:

• Included is not strictly necessary because we can compute if the status is Scheduled or Included based on the fork activation datetime and current datetime.
• TypeScript autocomplete would be nice when humans enter EIP data in a modern code editor, but would require changing EIP json files to ts files (and switching from ajv to something like zod). We already get compile time safety with ajv, so this would only really help with ergonomics in the editor.

[wolovim]

thanks for the lift!

focil did experience some whiplash, but ultimately the glamsterdam DFI + hegota CFI decision came in a package during acdc 171, so i've updated the statusHistory to that effect. also opportunistically updated a couple other stale eips while reviewing.

i'll address this separately, but when no dates/calls for any of the steps, i think a superior UX is to skip straight to only displaying the outcome in the timeline. e.g., proposed and scheduled steps are safe to assume based on context.

i hear you on TS autocompletion; the json choice is due to optimizing for easy contributions via github UI editing. my gut is that's still the right choice, but willing to debate it.

[dionysuzx]

i'll address this separately, but when no dates/calls for any of the steps, i think a superior UX is to skip straight to only displaying the outcome in the timeline. e.g., proposed and scheduled steps are safe to assume based on context.

after looking at a few examples, yes that makes sense to me. 👍

i hear you on TS autocompletion; the json choice is due to optimizing for easy contributions via github UI editing. my gut is that's still the right choice, but willing to debate it.

given the few benefits i see, a downside in github UI editing as mentioned, and the scope/complexity of the change, i definitely don't propose a shift to TS files, at least for now. perhaps a debate for another day!