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

[Michael Shigorin <mike@altlinux.org>]

On Mon, Sep 07, 2020 at 05:36:43PM +0300, Sergey V Turchin wrote:
> > > > или -- как в данном разе -- подключать переводчиков и
> > > > обеспечивать переводы вместо потери важной _целевой_
> > > > функциональности.
> > > Ты в курсе прогресса работ в этом направлении.
> > Потому вдвойне и удивился. :-) Хорошо же делают.
> Делают, но не сделали. А коммит был, когда перевода не было вообще.

Ты бы посмотрел, когда там "не было вообще".
В альт я собирал, помнится, уже переведя.

> > > > 2 zerg: в таких случаях в m-p по задумке принято не калечить
> > > > списки общего пользования,
> > > У меня другое мнение: я их исправил.
> > Обоснуй.  Это я в т.ч. как майнтейнер и многолетний активный
> > пользователь recoll спрашиваю.
> Пользуйся на здоровье, но не путай, пожалуйста, себя
> и пользователя дистрибутива.

И что, пара непереведённых строк в конфигурации индексирования
новой версии прям-таки сломает ему жизнь и выпьет кофе?

Ты забыл обосновать своё мнение.  Если оно чисто субъективное --
тогда этот коммит стоит откатить, если взяли, потому что моё
чисто субъективное мнение указано выше: это регрессия для m-p,
а в kworkstation с особыми требованиями к переводам следует
использовать какие-то отдельные списки (и, возможно, автотест
для определения стопроцентности перевода и блокирования сборки
в случае нарушения этого критерия -- см. в качестве примера
features.in/rescue/rescue/image-scripts.d/00-test-rescue).

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

Уже хорошо :-)

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

Более правильное решение тогда реализовал manowar@, загляни
в фичу pkgpriorities или просто git grep PINNED_PACKAGES.

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

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

Если приходится двигать фундамент -- это, конечно, сложнее,
но порой тоже бывает осмысленным (если бы была возможность
последние пять лет хоть иногда добираться до выпуска livecd
с игрушками -- возможно, у тебя не возникла бы такая нужда
уже для kworkstation; но уж как есть).

> > И выделить rescue+x11+extra, а "себе" забирать булевым выражением
> > 	$(call tags,rescue && x11 && !extra)
> > вместо
> > 	$(call tags,rescue x11)
> > -- по-моему, не так уж и сложно, было бы желание.
> Ок, возмьму на вооружение.
> Осталось для целей в make-файлах что-то придумать.

С целями труднее всего, угу.  Но порой можно выкрутиться
как-то вроде $(ISOHYBRID:%=use/isohybrid) в фиче syslinux
или $(UBOOT_TTY) в uboot.  Здесь сходу не вижу варианта.

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

> > > Вся суть m-p и состоит в разобщении списков. [...]
> > > Это его главный недостаток, который следует исправить.
> > Поясни, пожалуйста.
> Свои списки у каждого дистрибутива.

Оно-то да, но тут тоже есть что аккуратно обобщать.
Например, у меня тут лежат коммиты для фичи office,
которые после выпуска стартеркитов будем смотреть и,
надеюсь, мержить вместо того, чтоб по спискам пакетов
таскать хитрые исключения для конкретных архитектур:
http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles.git;a=shortlog;h=refs/heads/next
(2 antohami: пока не торопись, там были правки regular.mk
и между бетой и выпуском я бы их не стал предлагать)

> Выше указал на частичное решение, спасибо!

Ура :-)

> > PS: смотрел выхлоп REPORT=1 при установленном graphviz?
> Нет. Появился повод выбросить мусор и свой и чужой.

Чтоб выбрасывать чужой мусор, надо очень хорошо понимать в нём
-- ответственность куда больше, чем со своим...

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