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

Ср Окт 14 01:39:14 MSK 2020

ср, 14 окт. 2020 г. в 00:07, Vitaly Lipatov <lav на altlinux.ru>:
>
> 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,
> >> и
> >> нет конфликта с мантейнерами;
> >
> > Пусть решает. Но логичнее тогда забирать из нестабильного бранча,
> > создав свои службы тестирования и сопровождения.
> Мне кажется, что логичнее забирать из стабильного бранча, снизив
> нагрузку на службы тестирования и сопровождения, потому что тестирование
> частично будет осуществляться мантейнерами и частично — пользователями
> такого бранча. В таком случае в службу тестирования попадут уже
> прошедшие полевые испытания пакеты.

Это другая тема. По сути, Вы говорите о чем-то вроде testing и/или
experimental в Debian.
Но, замечу, что поим наблюдениям именно эти промежуточные бранчи
способствуют отставанию пакетной базы stable.
Не думаю также, что умы наберем много желающих пробовать такой бранч.

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

Насчет отдела тестироавния я написал выше. Еще раз: тестировщик --
отдельная профессия, тестирование им -- особая технология.
Профессиональное тестироввание не дело мейнтенера и пользователя. А
без такого тестирования нельзя выпускать продукты.
Отсальное, извините, слова.

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

См. то, что я написал про Debian.
Есть еще вариант Fedora, когда не слишком стабильные некоммерческие
дистрибутивы выпускаются при частичной стабилизации очень
нестабильного набора пакетов.  У нас тут есть некоторый аналог, --
регулярки раз в квартал. На выпуск же свободных Федор пока нет
ресурсов. Но если появятся желающие доводить регулярки до продуктов,
-- буду рад.

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

Стабильные бранчи мы и не бранчуем, но пытаемся ставилизировать к
релизу по результатам  работы отдела тестирования.

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