Поясните за бизнес-модель Fedora CI?

В freebsd то же самое. Только там грубо говоря base меньше а rpmfusion (портов) больше. И в общем то это единтсвенно приемлемая модель - в федоре значительную часть делают мантейнеры которые не на зряплате редхата, а редхат периодически делает срез и заморозку называя это RHEL X.Y

По ссылке не ходил, так как её нет. Из описания не вижу разницы между Fedora CI и RHEL. Срез и заморозка подразумевают интегрирование, согласование, дописывание и тестирование кучи разнородных пакетов из многих источников.

Какая разница?

Это выгоднее, чем классический срез и заморозка пакетов?

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

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

Не, мне вот с другой стороны, интересно было бы услышать, как происходит процесс в Микрософте, например?

У них же подход отличается. Они не пылесосят сторонние компоненты, а разрабатывают их в рамках своего дерева исходников.

Может конечно аналогично происходит федоровскому? Ну изменил там компонент, запустил тесты... по алгоритмам похожие на вот то. что в wiki fedora ci/cd.

alpha, mv

У вас там это дело не под NDA?

Ты путаешь модель доставки (срезал и заморозил) и модель разработки (CI).

Разработка не может быть по принципу заморозки, она всегда идет вперед. Да, в какой-то момент ты берешь срез текущего состояния, доводишь до ума и релизишь. Пользователи рады, но ты-то уже пошел разрабатывать дальше.

Если сравнивать разработку без CI и разработку с CI, то выглядит это примерно так:

в первом случае ты в течение некоторого времени накидываешь изменения в ветку в репе (если разработка проекта), в rawhide-репу (если разработка дистрибутива). После некоторого периода разработки ты включаешь режим интеграции: пытаешься смерджить свою ветку в mainline, или пытаешь собрать и запустить исошку и прогнать какие-нибудь тесты.

И практика показывает что сложность интеграции растет экспоненциально от количества изменений которые ты между шагами интеграции сделал.

Кроме того сложность вот этого интеграционного шага - «срезали и довели до ума» становится абсолютно непредсказуемой по трудоемкости. Это такая большая подстава, которая ждет тебя в (условном) конце разработки, когда ты уже вроде как собрался в отпуск и осталось «только собрать». Оказывается что это очень дорогостоящая операция, ломающая все планы, дедлайны и бонусы топ-менеджерам, и часто приводяющая к тому что часть фич надо просто заново переписывать, потому что они не проинтегрировались а стали работать друг против друга.

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

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

Это нормальная модель разработки?

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

См про debian

https://archive.fosdem.org/2017/schedule/event/distribution_ci/

Зачем тогда SilverBlue?

Это тоже скорее про доставку чем про разработку.

Fedora CI должен создавать пул интегрированных друг с другом пакетов. И собственно предоставлять возможность добавлять разные способы тестирования этих пакетов. Это уже дело майнтейнера конкретного пакета какие способы тестирования он выберет.

Дальше из этих пакетов ты можешь лепить исошку, можешь образы для контейнеров, можешь Flatpack или os-tree. Любой формат на твой выбор.

И Fedora Modularity сейчас работает на тем чтобы можно было создавать streams для параллельной поддержки нескольких версий одного и того же софта.

Главное не лопнуть от количества открывающихся возможностей.

Собственно поэтому и важна стабильность базы, тех самых old-school rpm-пакетов из которой это всё лепится.

Ой, ну спасибки! Разъяснила как надо.

Отмечаю как решенную.

Из всего вышесказанного, пока что вытекает что:

а) разработка в таком стиле замедляет бесконтрольное добавление новых фич (без мозгов добавили, но не скомпиляли).

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

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

г) снижает риск возникновения спонтанных конкурентов или риск лавинообразного развития конкурента (каноникла там, зюзи). Чтобы догнать, нужно будет вложить много денег спонсора или своих.

Очевидно, что срезовая модель приносит ожидаемые, но, всё же, неожиданные проблемы с каждым срезом. По-видимому, на столько, что в средне-долгосрочной перспективе дешевле «пылесосить» пакеты и ловить регрессии и баги ещё на дальних подступах. Чтобы в Федору неожиданностей попадало меньше, а в EL, желательно, вообще не попадало.

нет чтоб роллинг-релизы на сервера выкатывать, как все нормальные люди

нет чтоб роллинг-релизы на сервера выкатывать, как все нормальные люди

Есть немало бизнесов, где 4 часа простоя - это, значит, финансовый год закончится без прибыли, а 8 часов - банкротство.