Основні розробники Ethereum сперечаються щодо процесу та термінів Fusaka

Остання зустріч Ethereum’s All Core Devs була присвячена не лише коду, а й процесу: чи дотримуватися раніше оголошеного 30-денного інтервалу між випуском клієнта та першим форком тестнету, оскільки оновлення Fusaka просувається вперед. Деякі учасники наполягали на підтвердженні цього зобов’язання, щоб інфраструктурні та аплікаційні команди мали час адаптуватися; інші ж виступали за гнучкість, щоб уникнути затримок у ширшій дорожній карті.

Дискусія розгорталася на фоні змішаних результатів devnet. На Devnet-3, за словами Barnabas Busa з команди Dev Ops, запланована вправа з нефінальності затягнулася. “Ми хотіли спочатку провести приблизно два дні, а зараз вже п’ятий день,” — сказав він, зазначивши, що участь спочатку знизилася, а потім знову перевищила 50%. Для фінальності потрібно, щоб більше двох третин від загальної ефективної ставки погодилися.

Для порівняння, окремий тестнет швидко відновився після скоординованого перезапуску: “Ланцюг відновився, здається, за дві години,” — сказав Busa. Така вправа тестує, як змінні взаємодіють під час реального інциденту, що може допомогти Ethereum відновитися у кризовій ситуації.

Детальніше: Оновлення Fusaka для Ethereum може бути відкладене

Після впровадження виправлень у найближчі дні, короткостроковий план полягає у відновленні повної працездатності Devnet-3, повторному проведенні тесту та запуску Devnet-5.

Однак основною точкою напруги стала дисципліна планування для публічних мереж. Lightclient підкреслив існуючу обіцянку: “Там дійсно вказано 30 днів до першого тестнету.” Він застеріг від зміни цілей заради зручності, виходячи з оцінки основних розробників щодо часу, необхідного іншим командам, які не присутні на дзвінку.

Практичне питання полягає у тому, як покращити ритм хардфорків. Скорочення інтервалів між тестуваннями може прискорити форки, але підвищує ризик того, що команди, які залежать від них, випустять поспішені оновлення. Протилежний аргумент полягає в тому, що затяжні процеси затримують усе інше в черзі, чим ширша спільнота Ethereum може бути незадоволена.

“Я не думаю, що ми повинні обирати терміни, виходячи лише з побажань спільноти,” — сказав Lightclient. “Ті, хто випускає програмне забезпечення, сказали, що їм потрібно 30 днів, щоб надати якісний продукт, яким користуватиметься спільнота.”

Попри це, дещо напружений обмін думками схилився до дотримання письмового процесу, якщо тільки зацікавлені сторони явно не попросять про зміни.

Також було висловлено розчарування з приводу повторного обговорення одного й того ж питання кожного циклу. “Я вважаю, що це дуже поганий прецедент — постійно змінювати рішення,” — сказав Lightclient, зазначивши, що розробники додатків та L2 зазвичай не беруть участі у основних дзвінках і покладаються на передбачувані інтервали для планування власних релізів.

Наразі консенсус полягає у тому, щоб діяти так, ніби 30-денний буфер залишається чинним, водночас активно збираючи нові відгуки, сказав координатор Tim Beiko. “Ми повинні підготувати розклад згідно з [процесним] документом і паралельно перевірити це із зацікавленими сторонами, яких це стосується.” Якщо швидший шлях справді матиме широку підтримку, група формалізує це письмово.