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

[Andrey Savchenko <bircoph@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 16086 bytes --]

Добрый день!

On Tue, 13 Oct 2020 22:47:55 +0300 Vitaly Lipatov wrote:
> Давние поклонники сизифова труда наблюдали появление Sisyphus, потом, в 
> попытке усилить стабильность Sisyphus, а однажды даже пытался взлететь 
> Daedalus, предназначенный
> для крайне нестабильных версий пакетов. Чтобы создать условия для 
> разработки стабильного бранча сообществом, возникали бранчи типа t7.
> 
> Мне кажется, настало время поговорить о том, чтобы и Sisyphus оставить в 
> прошлом. По крайней мере, в его нынешнем виде.
> 
> Первый момент. Концепция вечно нестабильного репозитория, которым нельзя 
> пользоваться, не очень популярна среди пользователей.

Не говорите за всех, пожалуйста.

Как пользователь, я не вижу смысла использовать бранчи с устаревшим
софтом. В первую очередь потому, что, как говорит Брюс Шнайер,
безопасность — это не результат, безопасность — это процесс.
И как бы ни старались мейнтенеры бранчей, всех проблемы им не
закрыть, да и не всем уязвимостям дают CVE. И даже когда закроют —
это будет не сразу, т.к. процесс долгий, сперва бюрократия
(approve, ага), затем тестирование, где бюрократии ещё больше и она
ещё менее прозрачна. А эксплойты нередко начинают использовать
в течении суток после публикации информации, поэтому хуже старого
софта сложно что-то придумать.

Во вторых, как пользователю, мне нужны новые плюшки. Не во всём
софте и не всегда, но редко да метко. И ждать месяцами не горю
желанием.

В общем, для меня, как для пользователя Альта, всё, кроме Сизифа —
бесполезно.

Разумеется, это не значит, что бранчи бесполезны: есть много
категорий пользователей, которым предсказуемость, единообразие
и стабильность важнее всего остального. Понятно, что в корпоративной
среде нужен единообразный софт с одинаковыми версиями
и долгосрочной поддержкой — для таких задач только бранчи
и подходят; аналогично с поставщиками оборудования и всевозможных
встраиваемых решений.

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

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

Опять же, не говорите за всех. Как мейнтейнер я сам пользуюсь
Сизифом. Мало того, я стараюсь не связываться с бранчами, потому
что там долгая волокита и лишняя головная боль. Зачем мне, как
разработчику, это всё нужно? Дополнительная трата времени.

Но, безусловно, такой подход касается не всех: для многих состояние
бранчей очень важно и они сами ими пользуются — так что
замечательно, что у нас есть и такие разработчики.

С Сизифом я вижу одну проблему: отсутствие полноценного CI
тестирования. Виталий (vt@) предлагал реализацию такого для
автоматического тестирования базовой функциональности (например,
что система загружается после обновления). Но, к сожалению, его
предложение не было принято. Возможно, это хороший повод
переосмыслить предложенное и провести работы по CI в Сизифе.

> Второй момент. Понятие нестабильности сильно изменилось за прошедшие 
> годы. Повысился уровень квалификации в апстримах, больше соблюдается 
> семантическое версионирование в библиотеках, проекты делают стабильные 
> релизы, которые тестируются через CI, причём с серьёзными тестами. То 
> есть культура разработки изменилась. Тесты, Continuous Integration, 
> github, более доступная возможность pull requests. Наконец, сам Open 
> Source перестал быть маргинальным и стал мейнстримом. Всё это ведёт к 
> тому, что свободные проекты выпускают в стабильных релизах код высокого 
> качества, и даже более того, например, в wine каждый коммит вносит 
> атомарные изменения, подтверждённые тестами, то есть сборка из любого 
> коммита стабильна.

Апстримы апстримам рознь. Где-то CI, а где-то сотни сломанных
тестов, которые корректно работают только в очень специфических
условиях. Где-то сементическое версионирование в библиотеках,
а где-то забандленые статикой на уровне языка библиотеки и модули
(привет golang).

Количество систем сборок кода возрастает, многие крупные проекты
считают своим священным долгом изобрести собственную. Их безумие
тоже возрастает, чего стоят забитые в meson на уровне конфигов
апстрима свойства компилятора вместо проверки на реальном
компиляторе того, что он умеет. Ну а про всякие waf, dmake, gyp
и т.п. мерзость я вообще промолчу. Python даже в сборочную систему
glibc запихнули; ждём в ядре, run-time, systemd-kerneld-pythond.

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

Сложно сказать, какая из этих тенденций преобладает: сильно от
конкретного софта зависит, но в целом на уровне совокупности всего
ПО в дистрибутиве, по моему мнению, нагрузка на мейнтенеров
возрастает.

> Третий момент. Снижение роли мантейнера. В связи с ростом культуры 
> апстрима, 

Это очень спорно, см. выше.

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

Автоматизируются легко только весьма специфические классы пакетов,
как, например, массовые несложные модули языков (perl, ruby, python
и т.п.), где, по сути, есть своя система управления модулями
и нужно транслировать её в spec. Но и там возникают сложности, когда
пакеты становятся большими и нетривиальными, ну тот же numpy,
например.

Сложные пакеты неавтоматизируемы, за исключением некоторых рутинных
операций: glibc, binutils, gdb, kernel, libreoffice, qt и т.п.

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

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

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

Очень надеюсь, что таког оникогда не будет, потому что разработка
здорового дистрибутива всегда идёт сверху вниз: new -> stable
с градациями зависящими от дистрибутива.
 
> Отличия от нынешней схемы (они же — преимущества) я вижу такие:
> * бранчевание репозитория происходит в момент технологической 
> необходимости (когда весь мир переходит,

Нет такого, что «весь мир» переходит. Все решают для себя, многие
параллельно альтернативы поддерживают.

> когда отказались от xorg и 
> перешли на wayland и т.п., когда перешли на php 8 или python 4 или perl 
> 6, или когда решили вернуться на ffmpeg);

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

> * разработка мантейнерами ведётся в стабильном бранче, которым можно 
> пользоваться (он умеренно стабилен, на его основе можно делать выпуски 
> дистрибутивов community и т.п.);

Можно пользоваться с предложенным вами подходом? Смелое,
утверждение, однако, но верное лишь для подмножества пользователей,
см. мои комментарии в начале письма.

> Кстати, разработчикам не хватает доступного инструмента по проверке 
> пересобираемости (её умеют делать при тестировании для прохождения 
> пакетов в p9, но она плохо доступна мантейнерам Сизифа — мне ничего 
> неизвестно о таком инструменте). Ведь на самом деле большинство 
> библиотек имеет ограниченное количество «пользователей» (пакетов, 
> которые требуют их при сборке), поэтому такая пересборка не тяжела, 
> результат её не обязательно делать фатальным, но она точно приведёт к 
> снижению числа пакетов, которые неожиданно перестают собираться. Даже 
> cmake легко проверяется полной пересборкой использующих его пакетов, 
> хотя это достаточно популярное сборочное средство.

http://git.altlinux.org/people/ldv/packages/beehive.git

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]