[devel] Устаревшая концепция бранчей или стабильный бранч как основа разработки

Ср Окт 14 15:02:24 MSK 2020

Aleksey Novodvorsky писал 13.10.20 23:23:
> вт, 13 окт. 2020 г. в 22:48, Vitaly Lipatov <lav на altlinux.ru>:
>> 
...
> По моим наблюдениям, число пользователей Sisyphus растет, он повышает
> стабильность.
Да, это так, он повышает стабильность, поэтому я предлагаю лишить его
статуса «нестабильный». А что растёт число пользователей «нестабильного
репозитория», так это не от хорошей жизни. А от отсутствия выбора при
необходимости свежих версий.

> 
>  Например, p9.
>> Который является репозиторием компании и является точкой возникновения
>> конфликта интересов (на мой взгляд, тут есть проблема в публичном
>> сформулированном полиси развития такого репозитория, но это отдельная
>> тема).
> 
> Кто угодно может создать свой репозиторий, все открыто.
Это уже почти невозможно, поскольку требует серьёзной тяжёлой
инфраструктуры (например, сборочниц для всех платформ).
Кроме того, несмотря на заявление, что кто угодно может, реальных
примеров нет, итому есть причины (конечно, в Etersoft есть опыт «своего»
репозитория, но он добавочный, а не полноценный, и вообще не пример).

> Конечно, p9 ориентирован в значительной степени на продукты "Базальт
> СПО". И, что особенно важно, на их сопровождение. Для этого построена
> система тестирования пакетов, которая сейчас серьезно развита и
> развивается дальше. Без нее мы сейчас не могли бы обеспечить каество
> продуктов длявосьми аппаратных платформ.
Безусловно, всё это так.

>> 
>> Второй момент. Понятие нестабильности сильно изменилось за прошедшие
>> годы. Повысился уровень квалификации в апстримах, больше соблюдается
>> семантическое версионирование в библиотеках, проекты делают стабильные
>> релизы, которые тестируются через CI, причёмс серьёзными тестами. То
>> есть культура разработки изменилась. Тесты, Continuous Integration,
>> github, более доступная возможность pull requests. Наконец, сам Open
>> Source перестал быть маргинальным и стал мейнстримом. Всё это ведёт к
>> тому, что свободные проекты выпускают в стабильных релизах код 
>> высокого
>> качества, и даже более того, например, в wine каждый коммит вносит
>> атомарные изменения, подтверждённые тестами, то есть сборка из любого
>> коммита стабильна.
> 
> Это не вполне так. Посмотрите на число патчей в основных пакетах p9.
Конечно есть системообразующие пакеты, которые отражают специфику
дистрибутива, и вообще тщательная работа над пакетом добавляет к нему
штрихов. Но я про общую тенденцию. И чем дальше мы поднимаемся от ядра
системы, тем более переносимым становится пакет, и тем меньше там
дистрибутивных особенностей. Тут тоже есть тема, что имеются основные
(системообразующие) пакеты, так скажем, сердце системы ALT, а есть
(большей частью прикладные) пакеты, которые легко переносимы и не имеют
и не должны иметь дистрибутивных отличий в силу следования стандартам.
Это не всегда так, но к этому есть стремление.
Также у нас есть пример с ядром Linux, когда послепоявления там
концепции LTS-версий вереница патчей, накапливаемых внутри или
приносимых из Fedora/Debian, стабилизирующих или же дополняющих ядро
поддержкой нового оборудования, сильно уменьшилась — стабилизация и
бэкпортирование ведётся в унифицированном месте, и в этом заинтересованы
все игроки. Поправьте, если я неверно понял ситуацию с ядром.

>> Третий момент. Снижение роли мантейнера. В связи с ростом культуры
>> апстрима, а также с с большим количеством дистрибутивов, ведущих свою
>> сборку пакетов (что даёт некоторое количество мантейнеров, которые
>> смотрят на апстрим с разных сторон) большинство апстримов стали 
>> устроены
>> так, что упаковываются в пакет типовым образом и не требуют 
>> специальной
>> обработки. Конечно, я не о феноменах типа ghostscript, но и тому вроде
>> становится лучше. Тут я не то что констатирую факт, а настаиваю на 
>> том,
>> что роль мантейнера должна быть снижена, а часть его бессмысленной
>> работы — автоматизирована. Есть вещи, которые может и должен выполнять
>> человек, но это не относится к преобразованию спецификаций из одного
>> формата в другой. Мы всё же имеем дело не с естественным языком.
> 
> Снова не соглашусь. Наш вклад в апстрим растет и это говорит о
> повышении роли  и требованийк мейнтейнеру.
Наверное, я неверно предложил формулировку. Я имел в виду роль
мантейнера в выполнении рутинной работы (например, человеческого
внимания и нажатия клавиш просто для обновления до новой версии). Объём
рутинных действий должен уходить, освобождая время человека для анализа
и принятия решений, чего не сделает никакой скрипт. И речь идёт о
сопровождении общеупотребительных пакетов (практически без изменений
присутствующих в разных дистрибутивах). Я совсем не про вклад в апстрим.
Я скорее про разделение механической работы и соразработки, когда часть
апстримной разработки ведётся мантейнером наряду с сопровождением пакета
или для сопровождения пакета.

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

>> 
>> Возможно, что-то ещё я забыл упомянуть, поэтому и пишу сюда.
>> 
>> Если вкратце, то я предлагаю сделать p9 основным репозиторием
>> разработки, автоматически портируя все изменения в Сизиф.
> 
> И разработка будет застопорена, потому что никакой отдел тестирования
> не справится с нагрузкой,  а без тестирования не будет нормального
> сопровождения.
Безусловно, ноя не предлагал ничего про p9 :)
>> Это был «жёлтый» заголовок.

>> На самом деле предложение в том, чтобы основной веткой разработки стал
>> репозиторий, который бранчуется при крупных несовместимых изменениях
>> (например, критичных обновлениях тулчейна, glibc или KDE :)).
>> Репозитории Компании (p9 и т.д.) при этом забирают изменения из такого
>> репозитория согласно своим регламентам.
> 
> Бранчеванию предшестует концепция и всестороннее тестирование.
> Конечно, любая компания может попробовать любую схему.
Обсуждать концепцию бранчевания не входило в планы этого письма, вы
правильно заметили, что это отдельная задача, которую каждая компания
организует по своим требованиям. Я только коснулся этого, чтобы
показать, что бранчевать можно из стабильного репозитория, а не из
нестабильного.

>> Отличия от нынешней схемы (они же — преимущества) я вижу такие:
>> * бранчевание репозитория происходит в момент технологической
>> необходимости (когда весь мир переходит, когда отказались от xorg и
>> перешли на wayland и т.п., когда перешли на php 8 или python 4 или 
>> perl
>> 6, или когда решили вернуться на ffmpeg);
> 
> Наш цикл разработки приближается к циклу ведущих вендоров, а под них
> часто подстраивается апстрим, так как он с ними связан.
Вот, это я пытался сформулировать под словами «технологическая
необходимость», спасибо.

> Потому я полагаю, что нам стоит совершенствовать цикл разработки. Но
> он не может быть непредсказуем, так как, помимо прочего, завязан на
> бизнес.
Я как раз предлагаю немного развязать цикл разработки платформы и цикл
разработки стабильного бранча. Сделать возможность проскальзывания,
асинхронности. Иначе, как мне кажется, необходимость задерживать
развитие ради продуктового бранча, который нельзя обновить, будет только
негативнее сказываться на бранче (бизнесе на нём).

>> * разработка мантейнерами ведётся в стабильном бранче, которым можно
>> пользоваться(он умеренно стабилен, на его основе можно делать выпуски
>> дистрибутивов community и т.п.);
> 
> См. выше. Это паралич или отказ от тестирования.
Я бы предложил концепцию, по которой стабильность такого бранча можно
получать без тестирования выделенными тестировщиками. Сужу по своему
опыту того, какие проблемы находят в пакетах, которые я отправляю в p9.
К тому же мне кажется, что тестирование это тяжёлый труд, и я ни коим
образом не призываю его увеличить.

>> * Компания сама решает, какие изменения забирать в продуктовый branch, 
>> и
>> нет конфликта с мантейнерами;
> 
> Пусть решает. Но логичнее тогда забирать из нестабильного бранча,
> создав свои службы тестирования и сопровождения.
Мне кажется, что логичнее забирать из стабильного бранча, снизив
нагрузку на службы тестирования и сопровождения, потому что тестирование
частично будет осуществляться мантейнерами и частично — пользователями
такого бранча. В таком случае в службу тестирования попадут уже
прошедшие полевые испытания пакеты.

>> * крупные нестабильные обновления можно готовить в репозитории, 
>> который
>> будет являться дополнением к последнему бранчу (в чём-то это 
>> сокращение
>> идеи карманов https://www.altlinux.org/Pockets, а, может быть, и
>> наоборот, им приходит время, если таких нестабильных дополнений может
>> быть больше одного;
> 
> Это очень сырое предложение.
Это давно и неоднократно обсуждаемое предложение — не выбрасывать
огромное задание «новое KDE», которое неожиданно сломает всё у
пользователя, а предложить установить его сначала из кармана/таска и
попробовать. В сочетании с лёгким способом отката (downgrade до текущего
бранча) этот сопособ может стать популярным.
Тут может быть меня поддержит sin на .

>> * у сообщества разработчиков появляется стабильный бранч, в развитии и
>> стабильностикоторого они заинтересованы и могут пользоваться.
> 
> Это ресурсы. Кто профинансирует?
Я думаю, тут надо взвешивать также и профит от того, что ресурс для
продуктового бранча становится более живой и стабильный. Я предполагаю,
что можно найти подход, который привлечёт к разработке такого
стабильного бранча больше мантейнеров, в том числе и тех, которые не
понимают, зачем им что-то делать для p9 или не желают с ним связываться.
Как я написал, профит ещё и в снижении нагрузки на отдел тестирования.

> Да. Но 2Базальт СПО" не может такое выпускать в production
Возможно, я не смог донести свою мысль, что я просто предлагаю назвать
Сизиф стабильным, но сделатьего не одним репозиторием навсегда, а иногда
бранчевать. Эти бранчи «Базальт СПО» не должна никуда выпускать, они
по-прежнему остаются источником пакетов для продуктовых бранчей.

>> Таким образом мы получим стабильный репозиторий, который дискретно
>> переходит в новое стабильное состояние, исходя из технических
>> требований, и не приводя к бесконечным несовместимым изменениям за 
>> время
>> жизни репозитория. Это чем-то похоже на выпуски Fedora, но я не вижу
>> смысла делать бранчевание регулярным (привязанным к какому-то 
>> интервалу
>> времени), и нет необходимости (хотя возможно) публиковать дистрибутив 
>> на
>> каждом бранче.
> 
> Нравится или нет, но такая необходимость есть. И для дистрибутивов
> общего назначения и для сертифицированных, которые мы сейчас серьезно
> подтягиваем кстабильному бранчу. Замечу, что финансовое благополучие
> "Базальт СПО" в очень большой степени, хотя именьше, чем раньше,
> зависит от сертифицированных на конфиденциалку продуктов. Боюсь, что
> тенденции сейчас таковы, чтоэта зависимость может усилиться. И не
> только у нашей фирмы. А от финансов зависит инфраструктура разработки.
Опять же, я имел в виду, что, конечно же, у продуктовых бранчей своя
необходимость в появлении, и это решает Компания.
Я же писал о том, что нет необходимости регулярно бранчевать стабильный
бранч, который я предлагаю (пытаясь успеть к какому-то сроку).

>> Кстати, разработчикам не хватает доступного инструмента по проверке
>> пересобираемости (её умеют делать при тестировании для прохождения
...
> Вот с этим согласен.
> Вообще, продукт со средствами инфраструктуры разработки назрел.
> 
...
> Готовьте доклад в конце января в Переславле. Надеюсь, что обстановка
> позволит встретиться.
> 
> Спасибо!
:)

-- 
С уважением,
Виталий Липатов,
ALT Linux Team