Дискусії навколо термінів оновлень Ethereum: гнучкість чи жорсткість?

В останній зустрічі всіх розробників Ethereum обговорювалися процеси, а не просто код: чи варто дотримуватися раніше оголошеного 30-дневного терміну між випусками клієнтів та першим форком тестової мережі, оскільки оновлення Fusaka наближається. Деякі учасники наголошували на необхідності підтвердження цього зобов`язання, щоб команди інфраструктури та додатків мали час для адаптації; інші ж виступали за гнучкість, аби уникнути ширшого зрива графіка.

Дебати проходили на фоні змішаних результатів розробницької мережі. На Devnet-3 планувався тривалий експеримент з відсутності фіналізації, як зазначив Барнабас Буса з команди Dev Ops. `Ми хотіли зробити приблизно два дні спочатку, а тепер вже на п`ятому дні,` сказав він, зазначаючи, як участь знизилася, а потім знову піднялася вище 50%. Фіналізація вимагає, щоб більше двох третин загальної ефективної частки погодились.

На відміну від цього, окрема тестова мережа швидко відновилась після координованого перезапуску: `Ланцюг відновився в межах, я думаю, двох годин,` сказав Буса. Ця практика перевіряє, як змінні взаємодіють під час інциденту в реальному часі, що може допомогти Ethereum відновитися в кризовій ситуації.

Читати далі: Оновлення Fusaka в Ethereum може стикнутися з затримкою

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

Але більшим джерелом напруження була дисципліна розкладу для публічних мереж. Lightclient підкреслив постійну обіцянку: `Він дійсно говорить про 30 днів перед першим тестовим мережевим форком.` Він попередив про можливість змінювати терміни з причини зручності, базуючись на оцінці розробників основного програмного забезпечення від часу, необхідного іншим командам, які не були присутні на дзвінку.

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

`Я не думаю, що ми повинні обирати терміни на основі того, що спільнота, можливо, хоче,` сказав Lightclient. `Люди, які виготовляють програмне забезпечення, сказали, що хочуть 30 днів для поставки високоякісного програмного забезпечення, яким спільнота буде користуватися.`

Навіть так, дещо напружена дискусія drifted до підтримки написаного процесу, якщо зацікавлені сторони не запитують явно про зміну.

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

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