Почему

Одолела лень, потому я решил написать мое отношение к планам по хардфоркам. Я не претендую конечно на великомудрость, но свое слово сказать хочется. Может кто прислушается. Почему я простив смешивания функциональных изменений, затрагивающих консенсус и технических изменений.

Разделяй и влавствуй

Во первых по моему мнению это должно служить исключительно для того, что бы заставить людей, которым технические улучшалки неинтересны, но которые вынуждены обновляться на новую версию, тестировать технические изменения. Я даже сам это предложил в начале этого года в чате телеграма.

Вот к примеру сообщение от 11.02.2018

Я тогда предложил в чате совместить ХФ и СФ, что бы пойти на уступку goloscore, которые на тот момент уже пару месяцев работали на софтфорком, а тут появился небольшой шанс принятия ХФ не от goloscore, а от какого то там Гороха. Я понимал, что ребята просто могут заартачиться, просто обидно будет терять нажитое непосильным трудом и я их понимал. По этому я и сказал, что если набор фич в ХФ будет удовлетворять потребностям большинства, то народ подтянется к тестированию СФ. Так как будет вынужден. Даже я вызывался добровольцем. У меня была идея фикс - линейка. Я был готов потестировать.

Но это была вынужденная мера, что бы сдвинуть камень преткновения с места. Но как видно это понравилось goloscore и эту практику хотят внедрить и в последующих хардфорках.

И что получится в результате? Люди, которые реально зарабатывают на голосе, создавая приложения, будут вынужденны возможно тестировать ненужные им улучшалки/ухудшалки, только потому, что они включены в ХФ. Как будто людям заняться больше нечем, как играть роль тестировщика для goloscore.

Да и много ли людей тестировало? Я только @vvk да @vik -а видел. И @t3ran13 еще активно участвовал.

Бардак

Во вторых, смешивая функциональные и не-функциональные изменения усложняется тестирование фич. Человеку со стороны, без знаний внутренностей трудно отличить, толи это ошибка к примеру делегирования или просто сайт или ядро неправильно данные отдает. На примере тестирования этого ХФ 17.0 уже видно, что практически не было ни одного багфикса к функциональным изменениям, зато десятки к не-функциональным. x10 как минимум!

Допустим у меня приложение, работает, пол года уже, и еще сто лет проработало бы, так как пользуется ограниченным набором методов. Да вот взять тот же @habreplicator. Я его год назад написал (кстати мое первое приложение для голоса) и где-то запустил, даже не помню на каком сервере. Он до сих пор пашет как швейцарские часы. И я вынужден теперь тестировать ХФ, что бы эту приложуху портировать. Причем ничего из новых фич мне не нужно, и получается я тестирую не-функциональные изменения. Оно мне надо? Я может хочу на велосипеде лишний раз прокатиться.

Потому я предложил бы следующее.

ХФ выпускать миниум раз в три месяца. Для этого месяц отводить на разработку (по истечении месяца кат), месяц на тестирование и доводку, и месяц организационный - разбор полетов, подготовка бирж и приложений доноров, моральная поддержка делегатов, планирование слудующего спринта.
В промежутке, по необходимости выпускаются обновления, делается рефакторинг кода. Если кому то хочется какую-то улучшалку, он делает либо сам пул реквест, либо проси goloscore, если это что посложнее. И сколько надо выкатываются минорные версии. Заказчики и энтузиазисты тестируют SF.

В итоге, промежуточные минорные, оттестированные изменения так или иначе попадут в ХФ и будут взяты на вооружение. Первому, кто до сюда прочитал и отметит это в комментариях перечислю сто золотых.

Два месяца на ХФ, хоть из одной фичи, я считаю нереалистичным. Согласование, тестирование, адаптация, переезд займут только месяц. Делегаты не конвеер на заводе, это стадо баранов, которых надо еще согнать в кучу. А еще Биржа с ее требованиями, которую мы не хотим растраивать. Я думаю 3 месяца оптимальный отрезок времени. Даже судя по текущему ХФ. Плюс, чем больше приложений паразитирующих на блокчейне, тем инертнее масса, тем больше времени надо планировать на переезд.

Ну и сроки важны, даже для разработчиков. Тот же scrum учит, жестким временным рамкам на спринт и не зря. Разработчики привыкают, легче дается планирование коротких спринтов. "1-2 месяца на разработку"-план это не план, а гадание на кофейной гуще. 50% разброс в планировании - никуда не годится.

Ладно. Не буду утомлять своими нравоучениями. Я рад, что ХФ будет. Сижу и синкаю ноду.