Ethereum core devs spar over process, Fusaka timeline

Ethereum’s latest All Core Devs dwelled on process, not just code: whether to honor a previously stated 30-day window between client releases and the first testnet fork as the Fusaka upgrade inches forward. Some participants pushed to reaffirm the commitment so infrastructure and app teams have time to adapt; others argued for flexibility to avoid broader roadmap slippage.

The debate unfolded against a backdrop of mixed devnet results. On Devnet-3, a planned non-finality exercise ran long, per Barnabas Busa from the Dev Ops team. “We wanted to do approximately two days first, and now we’re hitting day five,” he said, noting how participation dipped and then crept back above 50%. Finality requires greater than two-thirds of the total effective stake agreeing.

By contrast, a separate testnet recovered quickly after a coordinated restart: “The chain has recovered within, I think two hours,” Busa said. The drill pressure-tests how variables interact in a live incident, which can help Ethereum recover in a crisis.

Read more: Ethereum’s Fusaka upgrade may face delay

With fixes landing in the coming days, the near-term plan is to restore Devnet-3 to full health, rerun the test and then spin up Devnet-5.

But the larger flashpoint was scheduling discipline for public networks. Lightclient underscored the standing promise: “It does say 30 days before the first testnet.” He warned against moving goalposts as a matter of convenience, based on core devs’ assessment of the time needed by other teams not present on the call.

The practical concern is how to improve the cadence of hard forks. Compressing gaps between testing can accelerate forks, but increases the risk that downstream teams ship rushed updates. The counterargument is that prolonged pipelines delay everything else in the queue, which the broader Ethereum community might be unhappy with.

“I don’t think we should choose timelines based on what the community necessarily wants,” Lightclient said. “The people who are shipping the software said they want 30 days to deliver high quality software that the community is going to use.”

Even so, the somewhat testy exchange drifted toward upholding the written process unless stakeholders explicitly ask for a change.

There was also frustration with revisiting the same question each cycle. “I just think it’s a really bad precedent to keep letting decisions change,” Lightclient said, noting that app developers and L2s aren’t typically on core calls and rely on predictable windows to schedule their own releases.

For now, the consensus is to proceed as if the 30-day buffer remains in force, while proactively soliciting fresh input, coordinator Tim Beiko said. “We should prep the schedule with what’s in the [process] document and then in parallel check with the stakeholders that are affected.” If a faster track truly has broad support, the group would formalize that in writing.