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

[Sergey V Turchin <zerg@altlinux.org>]

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.