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

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

[Vitaly Lipatov]

Давние поклонники сизифова труда наблюдали появление Sisyphus, потом, в 
попытке усилить стабильность Sisyphus, а однажды даже пытался взлететь 
Daedalus, предназначенный
для крайне нестабильных версий пакетов. Чтобы создать условия для 
разработки стабильного бранча сообществом, возникали бранчи типа t7.

Мне кажется, настало время поговорить о том, чтобы и Sisyphus оставить в 
прошлом. По крайней мере, в его нынешнем виде.

Первый момент. Концепция вечно нестабильного репозитория, которым нельзя 
пользоваться, не очень популярна среди пользователей. Также и несколько 
теряется смысл для мантейнеров — зачастую они собирают пакеты в этот 
репозиторий, а сами пользуются другим, более стабильным. Например, p9. 
Который является репозиторием компании и является точкой возникновения 
конфликта интересов (на мой взгляд, тут есть проблема в публичном 
сформулированном полиси развития такого репозитория, но это отдельная 
тема).

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

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

Возможно, что-то ещё я забыл упомянуть, поэтому и пишу сюда.

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

Это был «жёлтый» заголовок.

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

Отличия от нынешней схемы (они же — преимущества) я вижу такие:
* бранчевание репозитория происходит в момент технологической 
необходимости (когда весь мир переходит, когда отказались от xorg и 
перешли на wayland и т.п., когда перешли на php 8 или python 4 или perl 
6, или когда решили вернуться на ffmpeg);
* разработка мантейнерами ведётся в стабильном бранче, которым можно 
пользоваться (он умеренно стабилен, на его основе можно делать выпуски 
дистрибутивов community и т.п.);
* Компания сама решает, какие изменения забирать в продуктовый branch, и 
нет конфликта с мантейнерами;
* крупные нестабильные обновления можно готовить в репозитории, который 
будет являться дополнением к последнему бранчу (в чём-то это сокращение 
идеи карманов https://www.altlinux.org/Pockets, а, может быть, и 
наоборот, им приходит время, если таких нестабильных дополнений может 
быть больше одного;
* у сообщества разработчиков появляется стабильный бранч, в развитии и 
стабильности которого они заинтересованы и могут пользоваться.

На самом деле, благодаря тем «гайкам», которые неустанно закручивает 
ldv@ в части контроля целостности, собираемости (я про sisyphus_check и 
другие проверки собранных заданий) целостность и стабильность 
репозитория сильно выросла, и моменты, когда репозиторий развален, 
практически исключены (об этом можно судить также по достаточно редким 
случаям откатов репозитория). И эта стабильность делает возможным 
создания транзакционно стабильного репозитория (не знаю, в рамках тех 
суток, когда он публикуется).

Таким образом мы получим стабильный репозиторий, который дискретно 
переходит в новое стабильное состояние, исходя из технических 
требований, и не приводя к бесконечным несовместимым изменениям за время 
жизни репозитория. Это чем-то похоже на выпуски Fedora, но я не вижу 
смысла делать бранчевание регулярным (привязанным к какому-то интервалу 
времени), и нет необходимости (хотя возможно) публиковать дистрибутив на 
каждом бранче.

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

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

Извините, что это не доклад на конференции :)

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

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

[Aleksey Novodvorsky]

вт, 13 окт. 2020 г. в 22:48, Vitaly Lipatov <lav@altlinux.ru>:
>
>
> Давние поклонники сизифова труда наблюдали появление Sisyphus, потом, в
> попытке усилить стабильность Sisyphus, а однажды даже пытался взлететь
> Daedalus, предназначенный
> для крайне нестабильных версий пакетов. Чтобы создать условия для
> разработки стабильного бранча сообществом, возникали бранчи типа t7.
>
> Мне кажется, настало время поговорить о том, чтобы и Sisyphus оставить в
> прошлом. По крайней мере, в его нынешнем виде.
>
> Первый момент. Концепция вечно нестабильного репозитория, которым нельзя
> пользоваться, не очень популярна среди пользователей. Также и несколько
> теряется смысл для мантейнеров — зачастую они собирают пакеты в этот
> репозиторий, а сами пользуются другим, более стабильным.

По моим наблюдениям, число пользователей Sisyphus растет, он повышает
стабильность.

 Например, p9.
> Который является репозиторием компании и является точкой возникновения
> конфликта интересов (на мой взгляд, тут есть проблема в публичном
> сформулированном полиси развития такого репозитория, но это отдельная
> тема).

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

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

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

Снова не соглашусь. Наш вклад в апстрим растет и это говорит о
повышении роли  и требований к мейнтейнеру.

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

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

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

Бранчеванию предшестует концепция и всестороннее тестирование.
Конечно, любая компания может попробовать любую схему.

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

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

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

См. выше. Это паралич или отказ от тестирования.
> * Компания сама решает, какие изменения забирать в продуктовый branch, и
> нет конфликта с мантейнерами;

Пусть решает. Но логичнее тогда забирать из нестабильного бранча,
создав свои службы тестирования и сопровождения.
> * крупные нестабильные обновления можно готовить в репозитории, который
> будет являться дополнением к последнему бранчу (в чём-то это сокращение
> идеи карманов https://www.altlinux.org/Pockets, а, может быть, и
> наоборот, им приходит время, если таких нестабильных дополнений может
> быть больше одного;

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

Это ресурсы. Кто профинансирует?

>
> На самом деле, благодаря тем «гайкам», которые неустанно закручивает
> ldv@ в части контроля целостности, собираемости (я про sisyphus_check и
> другие проверки собранных заданий) целостность и стабильность
> репозитория сильно выросла, и моменты, когда репозиторий развален,
> практически исключены (об этом можно судить также по достаточно редким
> случаям откатов репозитория). И эта стабильность делает возможным
> создания транзакционно стабильного репозитория (не знаю, в рамках тех
> суток, когда он публикуется).

Да. Но 2Базальт СПО" не может такое выпускать в production

>
> Таким образом мы получим стабильный репозиторий, который дискретно
> переходит в новое стабильное состояние, исходя из технических
> требований, и не приводя к бесконечным несовместимым изменениям за время
> жизни репозитория. Это чем-то похоже на выпуски Fedora, но я не вижу
> смысла делать бранчевание регулярным (привязанным к какому-то интервалу
> времени), и нет необходимости (хотя возможно) публиковать дистрибутив на
> каждом бранче.

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

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

Вот с этим согласен.
Вообще, продукт со средствами инфраструктуры разработки назрел.

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

Готовьте доклад в конце января в Переславле. Надеюсь, что обстановка
позволит встретиться.

Спасибо!

Rgrds, Алексей

>
> --
> С уважением,
> Виталий Липатов,
> ALT Linux Team
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Aleksey Novodvorsky]

ср, 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

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

[Sergey V Turchin]

On Tuesday, 13 October 2020 22:47:55 MSK Vitaly Lipatov wrote:

[...]
> Третий момент. Снижение роли мантейнера. В связи с ростом культуры
> апстрима, а также с с большим количеством дистрибутивов, ведущих свою
> сборку пакетов (что даёт некоторое количество мантейнеров, которые
> смотрят на апстрим с разных сторон) большинство апстримов стали устроены
> так, что упаковываются в пакет типовым образом и не требуют специальной
> обработки. 
Абсолютно не согласен.
Апстримы не умели, не умеют и не будут никогда уметь делать пакеты.
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Например, они не будут паковать, как мы, несколько версий wine для одного 
репозитория. Про переход KDE с 3-ей на 4-ю вообще молчу.

> Конечно, я не о феноменах типа ghostscript, но и тому вроде
> становится лучше. Тут я не то что констатирую факт, а настаиваю на том,
> что роль мантейнера должна быть снижена, а часть его бессмысленной
> работы — автоматизирована.
Ни в коем случае. Никто кроме мантейнера не будет придумывать, как поженить 
несколько версий LLVM или gcc с конкретным дистрибутивом и какую версию вообще 
паковать.

> Есть вещи, которые может и должен выполнять
> человек, но это не относится к преобразованию спецификаций из одного
> формата в другой. Мы всё же имеем дело не с естественным языком.
Апсримы с горем пополам упакуют под пару попсоваых дистрибутивов(rpm и deb) и 
это будет более-менее сносно только потому, что в случае кривизны их толпой 
носом потыкают.
[...]

-- 
Regards, Sergey.

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

[Vitaly Lipatov]

Sergey V Turchin писал 14.10.20 10:06:
> On Tuesday, 13 October 2020 22:47:55 MSK Vitaly Lipatov wrote:
> 
> [...]
>> Третий момент. Снижение роли мантейнера. В связи с ростом культуры
>> апстрима, а также с с большим количеством дистрибутивов, ведущих свою
>> сборку пакетов (что даёт некоторое количество мантейнеров, которые
>> смотрят на апстрим с разных сторон) большинство апстримов стали 
>> устроены
>> так, что упаковываются в пакет типовым образом и не требуют 
>> специальной
>> обработки.
> Абсолютно не согласен.
> Апстримы не умели, не умеют и не будут никогда уметь делать пакеты.
Я имел в виду, что если апстрим смог наладить configure && make && make 
install, то ничего особого в спеке мантейнеру придумывать не придётся.
Конечно, я с удивлением смотрю, как апстримы выпекают сборки под разные 
системы, и у них это получается. Но конечно же, сборка пакетов не их 
профиль. Я не предлагал как-то полагаться на них в этом вопросе. Я 
только о том, что апстримы стали более пригодны к упаковке (на фоне 
того, что есть проекты, которые с большим трудом упаковке поддаются).

> ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
> Например, они не будут паковать, как мы, несколько версий wine для 
> одного
> репозитория. Про переход KDE с 3-ей на 4-ю вообще молчу.
...

>> Конечно, я не о феноменах типа ghostscript, но и тому вроде
>> становится лучше. Тут я не то что констатирую факт, а настаиваю на 
>> том,
>> что роль мантейнера должна быть снижена, а часть его бессмысленной
>> работы — автоматизирована.
> Ни в коем случае. Никто кроме мантейнера не будет придумывать, как 
> поженить
> несколько версий LLVM или gcc с конкретным дистрибутивом и какую версию 
> вообще
> паковать.
Возможно, я имел в виду, что разработчики апстрима обычно больше знают о 
своём проекте, и не стоит воображать себя более компетентным в их 
проекте.
Но я как раз о том, что автоматизируя рутинную работу, мы оставляем 
человеку больше времени придумывать — что с чем совместить и какую 
версию паковать.

>> Есть вещи, которые может и должен выполнять
>> человек, но это не относится к преобразованию спецификаций из одного
>> формата в другой. Мы всё же имеем дело не с естественным языком.
> Апсримы с горем пополам упакуют под пару попсоваых дистрибутивов(rpm и 
> deb) и
> это будет более-менее сносно только потому, что в случае кривизны их 
> толпой
> носом потыкают.
> [...]
Так а разве это не один и факторов успеха — утверждение Рэймонда, что 
«при наличии достаточного количества глаз все ошибки всплывают» («given 
enough eyeballs, all bugs are shallow»).
Количество ошибок в программе обычно уменьшается не в силу того, что 
разработчик поумнел, а в силу улучшения тестирования или жалоб от 
пользователей.

Я думаю, мы смотрим на разный опыт. Есть пакеты, которые не требуют 
интеллекта для упаковки, а есть сложные проекты (которым не мешало бы 
стать проще), требующие большого внимания и навыков. И я, конечно, про 
то, что в основном (по количеству пакетов, а не по объёму проектов) 
апстримы стали гораздо пригоднее к упаковке без хитростей.

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

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

[Sergey V Turchin]

On Wednesday, 14 October 2020 13:39:09 MSK Vitaly Lipatov wrote:
> Sergey V Turchin писал 14.10.20 10:06:
> > On Tuesday, 13 October 2020 22:47:55 MSK Vitaly Lipatov wrote:
> > 
> > [...]
> > 
> >> Третий момент. Снижение роли мантейнера. В связи с ростом культуры
> >> апстрима, а также с с большим количеством дистрибутивов, ведущих свою
> >> сборку пакетов (что даёт некоторое количество мантейнеров, которые
> >> смотрят на апстрим с разных сторон) большинство апстримов стали
> >> устроены
> >> так, что упаковываются в пакет типовым образом и не требуют
> >> специальной
> >> обработки.
> > 
> > Абсолютно не согласен.
> > Апстримы не умели, не умеют и не будут никогда уметь делать пакеты.
> 
> Я имел в виду, что если апстрим смог наладить configure && make && make
> install, то ничего особого в спеке мантейнеру придумывать не придётся.
> Конечно, я с удивлением смотрю, как апстримы выпекают сборки под разные
> системы, и у них это получается. Но конечно же, сборка пакетов не их
> профиль. Я не предлагал как-то полагаться на них в этом вопросе. Я
> только о том, что апстримы стали более пригодны к упаковке (на фоне
> того, что есть проекты, которые с большим трудом упаковке поддаются).
> 
> > ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
> > Например, они не будут паковать, как мы, несколько версий wine для
> > одного
> > репозитория. Про переход KDE с 3-ей на 4-ю вообще молчу.
> 
> ...
> 
> >> Конечно, я не о феноменах типа ghostscript, но и тому вроде
> >> становится лучше. Тут я не то что констатирую факт, а настаиваю на
> >> том,
> >> что роль мантейнера должна быть снижена, а часть его бессмысленной
> >> работы — автоматизирована.
> > 
> > Ни в коем случае. Никто кроме мантейнера не будет придумывать, как
> > поженить
> > несколько версий LLVM или gcc с конкретным дистрибутивом и какую версию
> > вообще
> > паковать.
> 
> Возможно, я имел в виду, что разработчики апстрима обычно больше знают о
> своём проекте, и не стоит воображать себя более компетентным в их
> проекте.
> Но я как раз о том, что автоматизируя рутинную работу, мы оставляем
> человеку больше времени придумывать — что с чем совместить и какую
> версию паковать.
> 
> >> Есть вещи, которые может и должен выполнять
> >> человек, но это не относится к преобразованию спецификаций из одного
> >> формата в другой. Мы всё же имеем дело не с естественным языком.
> > 
> > Апсримы с горем пополам упакуют под пару попсоваых дистрибутивов(rpm и
> > deb) и
> > это будет более-менее сносно только потому, что в случае кривизны их
> > толпой
> > носом потыкают.
> > [...]
> 
> Так а разве это не один и факторов успеха — утверждение Рэймонда, что
> «при наличии достаточного количества глаз все ошибки всплывают» («given
> enough eyeballs, all bugs are shallow»).
> Количество ошибок в программе обычно уменьшается не в силу того, что
> разработчик поумнел, а в силу улучшения тестирования или жалоб от
> пользователей.
Мантейнер любого дистрибутива _изначально_ упакует лучше и будет исправлять 
другие недочоты пакета и вносить улучшения вместо подтягивания штанов.

> Я думаю, мы смотрим на разный опыт. Есть пакеты, которые не требуют
> интеллекта для упаковки,
У нас есть chrombuild. Если пакет приемлем для установки со стороннего 
ресурса, то ему есть место на flathub, где уже многие представлены.

> а есть сложные проекты (которым не мешало бы
> стать проще), требующие большого внимания и навыков. И я, конечно, про
> то, что в основном (по количеству пакетов, а не по объёму проектов)
> апстримы стали гораздо пригоднее к упаковке без хитростей.
Это лишь облегчение работы _мантейнерам_ .

У апстримов своё, зачастую довольно абстрактное представление, как их софт 
должен жить в дистрибутиве. Мантейнеру может быть на это мнение плевать, если 
он _знает_ что ему необходимо по-другому и ему бывает нужно приложить усилия, 
чтоб сломать реализицию представления апстрима.

-- 
Regards, Sergey.

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

[Vitaly Lipatov]

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

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

[Anton Farygin]

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

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

[Arseny Maslennikov]

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

On Wed, Oct 14, 2020 at 10:06:26AM +0300, Sergey V Turchin wrote:
> On Tuesday, 13 October 2020 22:47:55 MSK Vitaly Lipatov wrote:
> 
> [...]
> > Третий момент. Снижение роли мантейнера. В связи с ростом культуры
> > апстрима, а также с с большим количеством дистрибутивов, ведущих свою
> > сборку пакетов (что даёт некоторое количество мантейнеров, которые
> > смотрят на апстрим с разных сторон) большинство апстримов стали устроены
> > так, что упаковываются в пакет типовым образом и не требуют специальной
> > обработки. 
> Абсолютно не согласен.
> Апстримы не умели, не умеют и не будут никогда уметь делать пакеты.
> ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
> Например, они не будут паковать, как мы, несколько версий wine для одного 
> репозитория. Про переход KDE с 3-ей на 4-ю вообще молчу.
> 
> > Конечно, я не о феноменах типа ghostscript, но и тому вроде
> > становится лучше. Тут я не то что констатирую факт, а настаиваю на том,
> > что роль мантейнера должна быть снижена, а часть его бессмысленной
> > работы — автоматизирована.
> Ни в коем случае. Никто кроме мантейнера не будет придумывать, как поженить 
> несколько версий LLVM или gcc с конкретным дистрибутивом и какую версию вообще 
> паковать.
> 
> > Есть вещи, которые может и должен выполнять
> > человек, но это не относится к преобразованию спецификаций из одного
> > формата в другой. Мы всё же имеем дело не с естественным языком.
> Апсримы с горем пополам упакуют под пару попсоваых дистрибутивов(rpm и deb) и 

А ещё бывает, что в апстриме есть debian maintainer, который всё
правильно сделает и сразу положит в репозиторий. См. meson, coturn,
проч.

> это будет более-менее сносно только потому, что в случае кривизны их толпой 
> носом потыкают.

Никто и не требует от апстримов _делать пакеты_. А вот тенденция к тому,
чтобы облегчить жизнь мейнтейнеру, есть. Не до всех она докатывается,
иногда технический долг тяжелее, да и 1% психбольных апстримов тоже есть, но.

Роль мейнтейнера, таким образом, всё менее становится рутинной и всё
более становится либо дежурной (реагировать на обновление, проверять
головой, давать отмашку на пересборку), либо связана с бекпортами,
которые никуда не денутся, но их тоже часто проще делать, либо
мейнтейнер ещё и участвует в апстриме и это 80% времени, которое он
тратит на пакет — и тогда это труд разработчика, которые нам (альту)
тоже очень нужны и полезны, в т. ч. для имиджа альта. Это, видимо, и
имел в виду Виталий отчасти, говоря об "уменьшении роли мейнтейнера".
Уменьшается роль, не сам мейнтейнер.

Критических пакетов (glibc, rpm, linux, pam, ...), требующих серьёзной
доработки для дистрибутива и поддержки этих доработок, меньшинство, и
это меньшинство скорее как минимум не растёт.

> [...]
> 
> -- 
> Regards, Sergey.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

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

[Sergey V Turchin]

On Wednesday, 14 October 2020 17:22:26 MSK Arseny Maslennikov wrote:

[...]
> А ещё бывает, что в апстриме есть debian maintainer, который всё
> правильно сделает и сразу положит в репозиторий. См. meson, coturn,
> проч.
Мантейнер Debian для Fedora нормально паковать не сможет, если у него нет 
опыта в несколько лет(упаковки совсем других различных пакетов).

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

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

> Роль мейнтейнера, таким образом, всё менее становится рутинной и всё
> более становится либо дежурной (реагировать на обновление, проверять
> головой, давать отмашку на пересборку), либо связана с бекпортами,
> которые никуда не денутся, но их тоже часто проще делать, либо
> мейнтейнер ещё и участвует в апстриме и это 80% времени, которое он
> тратит на пакет — и тогда это труд разработчика, которые нам (альту)
> тоже очень нужны и полезны, в т. ч. для имиджа альта. Это, видимо, и
> имел в виду Виталий отчасти, говоря об "уменьшении роли мейнтейнера".
> Уменьшается роль, не сам мейнтейнер.
Наоборот, увеличивается, т.к. увеличивается финкциональность и софт по 
умолчанию начинает лезть не так или не туда, куда ему надо. Раньше можно было 
упаковать HelloWord и не жужжать, а сегодня он превратился в LibreOffice.

> Критических пакетов (glibc, rpm, linux, pam, ...), требующих серьёзной
> доработки для дистрибутива и поддержки этих доработок, меньшинство, и
> это меньшинство скорее как минимум не растёт.
Я и говорю, что это во flatpack не запихаешь.

P.S.
В общем, вы пакуйте несколько LLVM параллельно, пакуйте. ;-)


-- 
Regards, Sergey.

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

[Arseny Maslennikov]

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

On Wed, Oct 14, 2020 at 05:46:00PM +0300, Sergey V Turchin wrote:
> On Wednesday, 14 October 2020 17:22:26 MSK Arseny Maslennikov wrote:
> 
> [...]
> > А ещё бывает, что в апстриме есть debian maintainer, который всё
> > правильно сделает и сразу положит в репозиторий. См. meson, coturn,
> > проч.
> Мантейнер Debian для Fedora нормально паковать не сможет, если у него нет 
> опыта в несколько лет(упаковки совсем других различных пакетов).

Ну он для debian прямо в debian и упаковывает, а с другими попсовыми
дистрибутивами всё так же.

> 
> > > это будет более-менее сносно только потому, что в случае кривизны их
> > > толпой
> > > носом потыкают.
> > Никто и не требует от апстримов _делать пакеты_.
> Я об этом и говорю, но мантейнеру так или иначе приходитсяч расхлёбывать, если 
> апстрим совершенно по другому понимает суть упаковки.
> 
> > А вот тенденция к тому, чтобы облегчить жизнь мейнтейнеру, есть.
> Тенденция и реальность не одно и то же. Например KDE5 мне усложнило жизнь, как 
> мантейнеру по сравнению с KDE4.

Да кто ж говорит, что нет исключений.

> <...>
> P.S.
> В общем, вы пакуйте несколько LLVM параллельно, пакуйте. ;-)
> 

*интрига повисла в воздухе*

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

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

[Sergey V Turchin]

On Wednesday, 14 October 2020 18:28:52 MSK Arseny Maslennikov wrote:

[...]
> > > А вот тенденция к тому, чтобы облегчить жизнь мейнтейнеру, есть.
> > Тенденция и реальность не одно и то же. Например KDE5 мне усложнило жизнь,
> > как мантейнеру по сравнению с KDE4.
> Да кто ж говорит, что нет исключений.
KDE слишком большой и немолодой проект. Он на исключение ну никак не тянет. 
Просто, у апстрима другое понимание, не соответствующее реальности, плюс 
некоторые реальные улучшения, но ведущие к усложнению работы мантейнера.

[...]

-- 
Regards, Sergey.

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

[Sergey V Turchin]

On Wednesday, 14 October 2020 18:28:52 MSK Arseny Maslennikov wrote:

[...]
> > <...>
> > P.S.
> > В общем, вы пакуйте несколько LLVM параллельно, пакуйте. ;-)
> *интрига повисла в воздухе*
Надеюсь вы не подумали, что апстрим это будет делать? ;-)

-- 
Regards, Sergey.

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

[Andrey Savchenko]

[-- 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 --]

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

[Alexey Gladkov]

On Tue, Oct 20, 2020 at 08:21:15PM +0300, Andrey Savchenko wrote:
> С Сизифом я вижу одну проблему: отсутствие полноценного CI
> тестирования. Виталий (vt@) предлагал реализацию такого для
> автоматического тестирования базовой функциональности (например,
> что система загружается после обновления). Но, к сожалению, его
> предложение не было принято. Возможно, это хороший повод
> переосмыслить предложенное и провести работы по CI в Сизифе.

Сделать что-то подобное (но лучше), что сделано в make-initrd. Набор
типовых разбивок корня в qemu и делать там dist-upgrade и reboot. Будет
гарантия, что хотя бы загружается в текстовом режиме.

-- 
Rgrds, legion

Re: [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

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

[Антон Мидюков]

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

Часть Сизифа, которая попадает в регулярки тестируется на базовое 
функционирование. Так что базовый функционал редко бывает разломан более 
нескольких дней.

[...]

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

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

[Anton Farygin]

On 20.10.2020 21:28, Alexey Gladkov wrote:
> On Tue, Oct 20, 2020 at 08:21:15PM +0300, Andrey Savchenko wrote:
>> С Сизифом я вижу одну проблему: отсутствие полноценного CI
>> тестирования. Виталий (vt@) предлагал реализацию такого для
>> автоматического тестирования базовой функциональности (например,
>> что система загружается после обновления). Но, к сожалению, его
>> предложение не было принято. Возможно, это хороший повод
>> переосмыслить предложенное и провести работы по CI в Сизифе.
> Сделать что-то подобное (но лучше), что сделано в make-initrd. Набор
> типовых разбивок корня в qemu и делать там dist-upgrade и reboot. Будет
> гарантия, что хотя бы загружается в текстовом режиме.
>
Для гарантии загрузки требуется проверять ещё и в разных конфигурациях, 
с разным количеством дисков и схемами разбивки.

Например, у нас был какое-то время сломан сценарий, когда не-корень 
находится на lvm (у меня пострадал swap) после обновления systemd.

CI в Sisyphus очень нужен, но этим пока что никто, кроме vt@ активно не 
занимался.

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

[Anton Farygin]

On 20.10.2020 23:58, Vitaly Lipatov wrote:
> Тут интересно, чем пользуются тестировщики при проверки собираемости в 
> p9. У меня есть подозрение, что чем-то другим. А если beehive, тогда 
> где-то есть и описание. 

пользуются beehive, описание для настройки не понадобилось.

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

[Alexey Gladkov]

On Wed, Oct 21, 2020 at 08:52:28AM +0300, Anton Farygin wrote:
> On 20.10.2020 21:28, Alexey Gladkov wrote:
> > On Tue, Oct 20, 2020 at 08:21:15PM +0300, Andrey Savchenko wrote:
> > > С Сизифом я вижу одну проблему: отсутствие полноценного CI
> > > тестирования. Виталий (vt@) предлагал реализацию такого для
> > > автоматического тестирования базовой функциональности (например,
> > > что система загружается после обновления). Но, к сожалению, его
> > > предложение не было принято. Возможно, это хороший повод
> > > переосмыслить предложенное и провести работы по CI в Сизифе.
> > Сделать что-то подобное (но лучше), что сделано в make-initrd. Набор
> > типовых разбивок корня в qemu и делать там dist-upgrade и reboot. Будет
> > гарантия, что хотя бы загружается в текстовом режиме.
> > 
> Для гарантии загрузки требуется проверять ещё и в разных конфигурациях, с
> разным количеством дисков и схемами разбивки.
> 
> Например, у нас был какое-то время сломан сценарий, когда не-корень
> находится на lvm (у меня пострадал swap) после обновления systemd.

Вот как раз такое я и имел в виду. Если проверять параллельно, то времени
будет уходить не фатально.

> CI в Sisyphus очень нужен, но этим пока что никто, кроме vt@ активно не
> занимался.

Тут нужно принять стратегическое решение. Плюс с вашей стороны нужна
помощь.

-- 
Rgrds, legion

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

[Andrey Savchenko]

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

On Wed, 21 Oct 2020 08:46:33 +0700 Антон Мидюков wrote:
> 21.10.2020 00:21, Andrey Savchenko пишет:
> > [...]
> > С Сизифом я вижу одну проблему: отсутствие полноценного CI
> > тестирования. Виталий (vt@) предлагал реализацию такого для
> > автоматического тестирования базовой функциональности (например,
> > что система загружается после обновления). Но, к сожалению, его
> > предложение не было принято. Возможно, это хороший повод
> > переосмыслить предложенное и провести работы по CI в Сизифе.
> 
> Часть Сизифа, которая попадает в регулярки тестируется на базовое 
> функционирование. Так что базовый функционал редко бывает разломан более 
> нескольких дней.

Проверяются ли там sysvinit системы? Я попадал на разлом из-за
проблем в udev, когда большинство модулей не грузилось.

Best regards,
Andrew Savchenko

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

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

[Антон Мидюков]

21.10.2020 14:29, Andrey Savchenko пишет:
> On Wed, 21 Oct 2020 08:46:33 +0700 Антон Мидюков wrote:
>> 21.10.2020 00:21, Andrey Savchenko пишет:
>>> [...]
>>> С Сизифом я вижу одну проблему: отсутствие полноценного CI
>>> тестирования. Виталий (vt@) предлагал реализацию такого для
>>> автоматического тестирования базовой функциональности (например,
>>> что система загружается после обновления). Но, к сожалению, его
>>> предложение не было принято. Возможно, это хороший повод
>>> переосмыслить предложенное и провести работы по CI в Сизифе.
>> Часть Сизифа, которая попадает в регулярки тестируется на базовое
>> функционирование. Так что базовый функционал редко бывает разломан более
>> нескольких дней.
> Проверяются ли там sysvinit системы? Я попадал на разлом из-за
> проблем в udev, когда большинство модулей не грузилось.

Проверяются: gnustep-sysv, icewm-sysv, jeos-sysv.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] Ресурсы для CI в Sisyphus или про review кода su из coreutuls

[Anton Farygin]

On 21.10.2020 09:59, Alexey Gladkov wrote:
> On Wed, Oct 21, 2020 at 08:52:28AM +0300, Anton Farygin wrote:
>> On 20.10.2020 21:28, Alexey Gladkov wrote:
>>> On Tue, Oct 20, 2020 at 08:21:15PM +0300, Andrey Savchenko wrote:
>>>> С Сизифом я вижу одну проблему: отсутствие полноценного CI
>>>> тестирования. Виталий (vt@) предлагал реализацию такого для
>>>> автоматического тестирования базовой функциональности (например,
>>>> что система загружается после обновления). Но, к сожалению, его
>>>> предложение не было принято. Возможно, это хороший повод
>>>> переосмыслить предложенное и провести работы по CI в Сизифе.
>>> Сделать что-то подобное (но лучше), что сделано в make-initrd. Набор
>>> типовых разбивок корня в qemu и делать там dist-upgrade и reboot. Будет
>>> гарантия, что хотя бы загружается в текстовом режиме.
>>>
>> Для гарантии загрузки требуется проверять ещё и в разных конфигурациях, с
>> разным количеством дисков и схемами разбивки.
>>
>> Например, у нас был какое-то время сломан сценарий, когда не-корень
>> находится на lvm (у меня пострадал swap) после обновления systemd.
> Вот как раз такое я и имел в виду. Если проверять параллельно, то времени
> будет уходить не фатально.
>
>> CI в Sisyphus очень нужен, но этим пока что никто, кроме vt@ активно не
>> занимался.
> Тут нужно принять стратегическое решение. Плюс с вашей стороны нужна
> помощь.
>
Как говорит aen@ - решение должен принят ldv, а ldv понимает, что за 
этим решением последует необходимость выделения ресурсов, в которые 
может всё это решение упереться.

как там с review su из coreutils ? всё упирается именно в этот же 
ресурс, который безусловно не маштабируется  и не умеет делегировать 
свои полномочия другим.

Re: [devel] CI для Сизифа

[Dmitry V. Levin]

On Tue, Oct 20, 2020 at 08:21:15PM +0300, Andrey Savchenko wrote:
[...]
> С Сизифом я вижу одну проблему: отсутствие полноценного CI
> тестирования. Виталий (vt@) предлагал реализацию такого для
> автоматического тестирования базовой функциональности (например,
> что система загружается после обновления). Но, к сожалению, его
> предложение не было принято. Возможно, это хороший повод
> переосмыслить предложенное и провести работы по CI в Сизифе.

Я думаю, Виталий (vt@) сделает, если захочет.
Но для полноценного CI потребуется активное участие мантейнеров
пакетов и дистрибутивов.


-- 
ldv

Re: [devel] про review кода su из coreutuls

[Dmitry V. Levin]

On Wed, Oct 21, 2020 at 10:58:58AM +0300, Anton Farygin wrote:
[...]
> как там с review su из coreutils ? всё упирается именно в этот же 
> ресурс, который безусловно не маштабируется  и не умеет делегировать 
> свои полномочия другим.

Не вижу смысла собирать su из coreutils.


-- 
ldv

Re: [devel] про review кода su из util-linux

[Anton Farygin]

On 21.10.2020 13:01, Dmitry V. Levin wrote:
> On Wed, Oct 21, 2020 at 10:58:58AM +0300, Anton Farygin wrote:
> [...]
>> как там с review su из coreutils ? всё упирается именно в этот же
>> ресурс, который безусловно не маштабируется  и не умеет делегировать
>> свои полномочия другим.
> Не вижу смысла собирать su из coreutils.

Точно, что-то я совсем закрутился. Из util-linux, конечно:

https://bugzilla.altlinux.org/show_bug.cgi?id=23700

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

[mikhailnov]

20.10.2020 21:28, Alexey Gladkov пишет:
> On Tue, Oct 20, 2020 at 08:21:15PM +0300, Andrey Savchenko wrote:
>> С Сизифом я вижу одну проблему: отсутствие полноценного CI
>> тестирования. Виталий (vt@) предлагал реализацию такого для
>> автоматического тестирования базовой функциональности (например,
>> что система загружается после обновления). Но, к сожалению, его
>> предложение не было принято. Возможно, это хороший повод
>> переосмыслить предложенное и провести работы по CI в Сизифе.
> Сделать что-то подобное (но лучше), что сделано в make-initrd. Набор
> типовых разбивок корня в qemu и делать там dist-upgrade и reboot. Будет
> гарантия, что хотя бы загружается в текстовом режиме.
>
Описанное несколько лет назад тестирование сравнением скриншотов мне по-прежнему кажется жизнеспособной идеей.

https://lists.altlinux.org/pipermail/sisyphus/2018-April/366621.html