[devel-distro] переводы, списки, форки (was: коммиты для kworkstation)

[Michael Shigorin]

On Mon, Sep 07, 2020 at 11:23:43AM +0300, Sergey V Turchin wrote:
> > или -- как в данном разе -- подключать переводчиков и
> > обеспечивать переводы вместо потери важной _целевой_
> > функциональности.
> Ты в курсе прогресса работ в этом направлении.

Потому вдвойне и удивился. :-) Хорошо же делают.  А что когда-то
отстаёт -- тут или работать с апстримами на этапе подготовки
выпусков, или переводить (и тестировать да класть в дистрибутивы)
только отобранные выпуски.  Это чисто организационный вопрос,
а с таким подходом можешь смело выкидывать из списков вообще всё.
Проблем в переводах море ещё с тех пор, как до них дорвались
убунтушники.

> > 2 zerg: в таких случаях в m-p по задумке принято не калечить
> > списки общего пользования,
> У меня другое мнение: я их исправил.

Обоснуй.  Это я в т.ч. как майнтейнер и многолетний активный
пользователь recoll спрашиваю.

> > а или выделять нужную часть,
> Мне неудобно городить своё отдельное дерево и отслеживать
> изменения в тех местах, которые я копирую.

Тогда учись договариваться, а не как с branding-xalt-kworkstation, 
который теперь в версиях системных компонент вроде xorg-server
"красуется": "мне так удобно, а до вас всех мне дела нет" :-/

На сейчас предусмотрены варианты:
1) общих списков/фич, которые должны устраивать _всех_
   пользователей данной ветки (и исправляться/улучшаться
   коллегиально);
2) частных реализаций (например, slinux), которые если
   применяются другими -- то на свой страх и риск.

Конкретно в rescue+x11 изменений за всё время после создания
был целый десяток, если что.

И выделить rescue+x11+extra, а "себе" забирать булевым выражением

	$(call tags,rescue && x11 && !extra)

вместо

	$(call tags,rescue x11)

-- по-моему, не так уж и сложно, было бы желание.

> Вся суть m-p и состоит в разобщении списков. От прошлого
> проекта имени boyarsh@ он в основном только этим и
> отличается(для мантейнера дистрибутива).  Это его главный
> недостаток, который следует исправить.

Поясни, пожалуйста.  А то начнёшь "исправлять" фундаментальное
преимущество с точки зрения ~всех остальных майнтейнеров
дистрибутивов, проще будет заново написать (кстати, если кто
соберётся продумывать следующее поколение систем управления
конфигурацией для сборки альтовых дистрибутивов -- пишите,
были некоторые задумки и выводы).

"Разобщение" -- это по сути тонкие блокировки; если предпочитаешь
big kernel lock -- имей в виду, вообще не масштабируется.
В пределе: если всю генерацию дистрибутива слить в один большой
скрипт, любые два коммита на одно и то же состояние будут
кандидатами на конфликт, в лучшем случае подходящими под
автоматический merge.

PS: смотрел выхлоп REPORT=1 при установленном graphviz?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info