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

[Sergey V Turchin]

On Monday, 7 September 2020 16:56:00 MSK Michael Shigorin wrote:
> 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)
> -- по-моему, не так уж и сложно, было бы желание.
Ок, возмьму на вооружение.
Осталось для целей в make-файлах что-то придумать.

> > Вся суть m-p и состоит в разобщении списков. От прошлого
> > проекта имени boyarsh@ он в основном только этим и
> > отличается(для мантейнера дистрибутива).  Это его главный
> > недостаток, который следует исправить.
> 
> Поясни, пожалуйста.  А то начнёшь "исправлять" фундаментальное
> преимущество с точки зрения ~всех остальных майнтейнеров
> дистрибутивов, проще будет заново написать (кстати, если кто
> соберётся продумывать следующее поколение систем управления
> конфигурацией для сборки альтовых дистрибутивов -- пишите,
> были некоторые задумки и выводы).
Свои списки у каждого дистрибутива. Выше указал на частичное решение, спасибо!

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

-- 
Regards, Sergey.