Дебаты о соблюдении 30-дневного интервала между обновлениями Ethereum: гибкость или строгость?

Этикетка разработчиков Ethereum обсуждает процесс, а не только код: следует ли соблюдать ранее заявленный 30-дневный интервал между релизами клиентов и первым тестовым форком по мере того, как обновление Fusaka приближается. Некоторые участники настаивали на подтверждении приверженности этому принципу, чтобы у инфраструктурных и приложенческих команд было время для адаптации; другие же выступали за гибкость, чтобы избежать более широких сдвигов в дорожной карте.

Дебаты развернулись на фоне смешанных результатов devnet. На Devnet-3 запланированное упражнение по неокончательности затянулось, по словам Барнабаса Бусы из команды Dev Ops. «Мы хотели сделать это примерно за два дня, а теперь мы достигли пятого дня,» - сказал он, отметив, что участие сначала упало, а затем вернулось обратно выше 50%. Окончательность требует согласия более двух третей от общего эффективного залога.

В отличие от этого, отдельный тестнет быстро восстановился после скоординированного перезапуска: «Цепочка восстановилась, я думаю, за два часа,» - сказал Буса. Это упражнение тестирует, как переменные взаимодействуют в условиях реального инцидента, что может помочь Ethereum восстановиться в кризисной ситуации.

С исправлениями, появляющимися в ближайшие дни, краткосрочный план - восстановить Devnet-3 до полной работоспособности, повторно провести тест и затем запустить Devnet-5.

Но более крупной точкой напряжения была дисциплина расписания для публичных сетей. Лайт-клиент подчеркнул стоящую обещание: «Это говорит о 30 днях перед первым тестнетом.» Он предостерег от изменения целей лишь из удобства, основываясь на оценке времени, необходимого другим командам, которые не присутствовали на вызове.

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

«Я не думаю, что мы должны выбирать сроки на основе того, чего хочет сообщество,» - сказал Лайт-клиент. «Люди, которым нужно отправить программное обеспечение, сказали, что им нужно 30 дней, чтобы представить качественное ПО, которым будет пользоваться сообщество.»

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

Также была выражена фрустрация повторным обсуждением одного и того же вопроса в каждом цикле. «Я просто думаю, что это действительно плохой прецедент - продолжать позволять менять решения,» - сказал Лайт-клиент, отметив, что разработчики приложений и L2 обычно не участвуют в основных встречах и зависят от предсказуемых временных окон для планирования своих собственных релизов.

На данный момент консенсус состоит в том, чтобы продолжать считать, что 30-дневный буфер остается в силе, одновременно активно запрашивая новое мнение, сказал координатор Тим Бейко. «Мы должны подготовить расписание с учетом того, что в документе [процесса], а затем параллельно проверить с затронутыми заинтересованными сторонами.» Если более быстрый трек действительно имеет широкую поддержку, группа оформит это в письменном виде.