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

[Vitaly Lipatov]

Andrey Savchenko писал 20.10.20 20:21:
...
>> Первый момент. Концепция вечно нестабильного репозитория, которым 
>> нельзя
>> пользоваться, не очень популярна среди пользователей.
> 
> Не говорите за всех, пожалуйста.
Вы хотите сказать, что у кого-то популярна концепция репозитория, 
которым нельзя пользоваться? :) Мне кажется, причина другая.
Я на всякий случай ещё раз повторюсь, что я излагал своё мнение, и 
полагал, что при этом не требуется оговаривать всё время, что я говорю 
не за всех :)

> Как пользователь, я не вижу смысла использовать бранчи с устаревшим
> софтом. В первую очередь потому, что, как говорит Брюс Шнайер,
Понятно, что стабильный репозиторий со свежим софтом — это то, чего всем 
не хватает.
Но всё же вы не пользователь. Пользователю в силу ограниченности 
возможностей взаимодействия с репозиторием приходится идти на 
компромиссы (читай — использование бранча с устаревшим софтом).

...> ещё менее прозрачна. А эксплойты нередко начинают использовать
> в течении суток после публикации информации, поэтому хуже старого
> софта сложно что-то придумать.
Очень поддерживаю этот подход. Вовремя не обновился — уже проиграл. 
Собственно поэтому я и говорил о том, что надо сделать Сизиф более 
пригодным для пользователя. Просто при этом я его назвал стабильным 
бранчем.

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

> В общем, для меня, как для пользователя Альта, всё, кроме Сизифа —
> бесполезно.
Возможно, я был не прав, и пользователи Альта это такие особенные 
пользователи, которые могут и пакет откатить, и initrd отладить.

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

>> Также и несколько
>> теряется смысл для мантейнеров — зачастую они собирают пакеты в этот
>> репозиторий, а сами пользуются другим, более стабильным.
> 
> Опять же, не говорите за всех. Как мейнтейнер я сам пользуюсь
> Сизифом.
Я тоже как мантейнер пользуюсь Сизифом. Собираю в нём пакеты. Но кроме 
него у меня ещё сотня систем на стабильном бранче. При такой статистике 
я не могу говорить, что пользуюсь Сизифом.

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

...
> Апстримы апстримам рознь. Где-то CI, а где-то сотни сломанных
> тестов, которые корректно работают только в очень специфических
> условиях. Где-то сементическое версионирование в библиотеках,
> а где-то забандленые статикой на уровне языка библиотеки и модули
> (привет golang).
> 
> Количество систем сборок кода возрастает, многие крупные проекты
> считают своим священным долгом изобрести собственную. Их безумие
> тоже возрастает, чего стоят забитые в meson на уровне конфигов
> апстрима свойства компилятора вместо проверки на реальном
> компиляторе того, что он умеет. Ну а про всякие waf, dmake, gyp
> и т.п. мерзость я вообще промолчу. Python даже в сборочную систему
> glibc запихнули; ждём в ядре, run-time, systemd-kerneld-pythond.
> 
> Мораль простая: есть как тенденция по улучшению качества кода
> и наведению порядка, так и тенденция по усложнению сборочных
> систем, увеличению числа фич, зависимостей, общему увеличению
> количества пакетов и росту как их собственной сложности, так и
> сложности взаимосвязей между ними.
> 
> Сложно сказать, какая из этих тенденций преобладает: сильно от
> конкретного софта зависит, но в целом на уровне совокупности всего
> ПО в дистрибутиве, по моему мнению, нагрузка на мейнтенеров
> возрастает.
Спасибо за картину, тенденции действительно разные.

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

> Сложные пакеты неавтоматизируемы, за исключением некоторых рутинных
> операций: glibc, binutils, gdb, kernel, libreoffice, qt и т.п.
> 
> Просто посмотрите на количество патчей в любых дистрибутивах,
> особенно на тулчейн. И после этого не говорите ерунды про то, что
> апстримы делают пакеты, которые можно прямо из коробки в
> дистрибутиве использовать.
Тулчейн это антипример, который как раз подтверждает правило. К тому же 
просто тулчейны никому не нужны, поэтому они в таком состоянии. 
Тулчейном пользуются те, кто его не разрабатывает. И разрабатывают те, 
кто в общем-то его не использует. А если и использует, то на разработку 
внимания остаётся мало времени.
На количество патчей я смотрю, и их количество это плохой признак. И 
тулчейны я собираю, тут чем меня удивлять.

> Для сложных пакетов нагрузка на мейнтенера наоборот возрастает,
> т.к. растёт сложность самих пакетов.
Рост сложности может и должен происходить внутри, с внешним упрощением.
Чтобы за пределы configure && make ничего не выходило.

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

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

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

>> Кстати, разработчикам не хватает доступного инструмента по проверке
>> пересобираемости (её умеют делать при тестировании для прохождения
...
> http://git.altlinux.org/people/ldv/packages/beehive.git
Поиск по вики слова beehive даёт «я рылся grep'ом в логах beehive»
Возможно, именно beehive я имел в виду, когда писал «не хватает 
доступного инструмента».
Пока что мне кажется, что beehive это не инструмент, это программная 
часть ldv на .

Тут интересно, чем пользуются тестировщики при проверки собираемости в 
p9. У меня есть подозрение, что чем-то другим. А если beehive, тогда 
где-то есть и описание.




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