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