ALT Linux Bugzilla – #49644

Created attachment 15669 [details]
gpg ключ

(Ответ для Boris Yumankulov на комментарий #0)
...
> Ментор: Виталий Липатов <lav@altlinux.org>
Подтверждаю менторство.

Ментор есть, ключи в порядке.
T/J/S -> 1.3.

2.0 Кандидат готов начать вступление.

ssh ключ на gitery.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.3.

Собран пакет: Distrobox

Github: https://github.com/89luca89/distrobox

Репо: https://git.altlinux.org/people/boria138/packages/?p=distrobox.git;a=summary

3.0. Кандидат готов собирать пакеты.

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

T/J/S -> 3.6.

Собран пакет: NoteBook FanControl
github: https://github.com/nbfc-linux/nbfc-linux

Репо: https://git.altlinux.org/people/boria138/packages/?p=nbfc-linux.git;a=summary
Таска: https://packages.altlinux.org/en/tasks/349948/

Собран пакет: ProtonPlus
github: https://github.com/Vysp3r/ProtonPlus

Репо: https://git.altlinux.org/people/boria138/packages/?p=protonplus.git;a=summary
Таска: https://packages.altlinux.org/en/tasks/349934/

Собран Distrobox 
Таска: https://packages.altlinux.org/en/tasks/349896/

Собран пакет: Aurea
github: https://github.com/CleoMenezesJr/Aurea/

Репо: https://git.altlinux.org/people/boria138/packages/?p=aurea.git;a=summary
Таска: https://packages.altlinux.org/ru/tasks/350254/

Собран пакет: Ptyxis
gitlab: https://gitlab.gnome.org/chergert/ptyxis

Репо: https://git.altlinux.org/people/boria138/packages/?p=ptyxis.git;a=summary
Таска: https://packages.altlinux.org/ru/tasks/350730/

Пришолось собрать патченный vte и приложить библиотеки от него в пакет иначе пакет не собирается и не запускается

Собран пакет: onnx
github: https://github.com/onnx/onnx

Репо: https://git.altlinux.org/people/boria138/packages/?p=onnx.git;a=summary
Таска: https://packages.altlinux.org/ru/tasks/351066/

Собран пакет: zram-generator
github: https://github.com/systemd/zram-generator

Репо: https://git.altlinux.org/people/boria138/packages/?p=zram-generator.git;a=summary
Таска: https://packages.altlinux.org/ru/tasks/351104/

Предлагаю в devel пакетах с Си хедерами указывать Group: Development/C

(In reply to Vitaly Chikunov from comment #14)
> Предлагаю в devel пакетах с Си хедерами указывать Group: Development/C

Поменял группу

Обновил пакет ptyxis до 46.3

Таска: https://packages.altlinux.org/en/tasks/351201/

Выделил всё что касается vte в отдельный подпакет libvte-ptyxis

Исправил ошибку пересборки nbfc-linux из-за смены макросов

Таска: https://packages.altlinux.org/ru/tasks/351359

Сделал NMU на lowdown для добавления devel пакета

Таска: https://packages.altlinux.org/ru/tasks/351162

Собран пакет: libeditline
github: https://github.com/troglobit/editline

Репо: https://git.altlinux.org/people/boria138/packages/?p=libeditline.git;a=summary
Таска: https://packages.altlinux.org/en/tasks/351887

Обновил пакет ptyxis до 46.4

Таска: https://packages.altlinux.org/en/tasks/351859/

4.0

Собранные выше пакеты отправлены в Сизиф.

Считаю, что Борис готов отправлять пакеты в Сизиф самостоятельно.

Собран пакет: nix
github: https://github.com/NixOS/nix

Репо: https://git.altlinux.org/people/boria138/packages/?p=nix.git;a=summary
Таска: https://packages.altlinux.org/en/tasks/351975

Собран пакет firmware-nouveau

Репо: https://git.altlinux.org/people/boria138/packages/?p=firmware-nouveau.git;a=summary
Бага: https://bugzilla.altlinux.org/50851
Таска: https://packages.altlinux.org/en/tasks/352326/

Пакет по сути набор прошивок nvidia которые нужны для поддержки аппартного ускорения видео на nouveau

Обновил nix до версии 2.23.3
Таска: https://packages.altlinux.org/en/tasks/352622/

Обновил ptyxis до версии 46.5
Таска: https://packages.altlinux.org/en/tasks/352621/

Обновил ProtonPlus до версии 0.4.11
Таска: https://packages.altlinux.org/en/tasks/353116/

Собран пакет: liboneapi-level-zero1
github: https://github.com/oneapi-src/level-zero

Репо: https://git.altlinux.org/people/boria138/packages/?p=liboneapi-level-zero1.git;a=summary
Таска: https://packages.altlinux.org/ru/tasks/354108/

Собран пакет: libintel-opencl-clang
github: https://github.com/intel/opencl-clang

Репо: https://git.altlinux.org/people/boria138/packages/?p=libintel-opencl-clang.git;a=summary
Таска: https://packages.altlinux.org/ru/tasks/354118/

Собран пакет: libvc-intrinsics
github: https://github.com/intel/vc-intrinsics

Репо: https://git.altlinux.org/people/boria138/packages/?p=libvc-intrinsics.git;a=summary
Таска: https://packages.altlinux.org/ru/tasks/354107/

Обновил ptyxis до версии 46.6
Таска: https://packages.altlinux.org/en/tasks/354930/

Собран пакет: libtoml11
github: https://github.com/ToruNiina/toml11

Репо: https://git.altlinux.org/people/boria138/packages/?p=libtoml11.git;a=summary
Таска: https://packages.altlinux.org/en/tasks/355318/

Обновил liboneapi-level-zero1 до версии 1.17.28
Таска: https://packages.altlinux.org/en/tasks/355316/

Обновил nix до версии 2.24.2
Таска: https://packages.altlinux.org/en/tasks/355457/

Призван рецензент (rider@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

Из свежего:
https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/3148729581672545815

1) При наличии апстримного гита схема сборки выбрана без его использования. Этот вопрос ко всем собранным пакетам.

2) в секции files используется путь к файлу без макросов - зачем ?
  49 /usr/lib/systemd/system-generators/zram-generator

Пакет nix собран без учёта SharedLibsPolicy:
https://packages.altlinux.org/ru/tasks/361634/

%configure --localstatedir=/nix/var --disable-tests --disable-unit-tests --disable-doc-gen --enable-gc

1) Надо включить тесты (во всех пакетах, в которых тесты есть)
2) почему localstatedir=/nix/var ?

Все пакеты отдавайте на review только мне, не надо их аппрувить ментором.

Как исправите - напишите.

https://packages.altlinux.org/ru/sisyphus/srpms/liboneapi-level-zero1/

Вот этот пакет собран вообще неправильно (не в соответствии с SharedLibsPolicy), мы его сейчас переделаем, а этот придётся удалить.

(Ответ для Anton Farygin на комментарий #32)
> Из свежего:
> https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/
> 3148729581672545815
> 
> 1) При наличии апстримного гита схема сборки выбрана без его использования.
> Этот вопрос ко всем собранным пакетам.

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

> 2) в секции files используется путь к файлу без макросов - зачем ?
>  49 /usr/lib/systemd/system-generators/zram-generator


По моему когда я собирал zram-generator макроса %_systemdgeneratordir не было, или я невнимательно смотрел, переделаю на макрос

365032 TESTED #1 [test-only] sisyphus zram-generator.git=1.2.1-alt2

(Ответ для Anton Farygin на комментарий #34)
> %configure --localstatedir=/nix/var --disable-tests --disable-unit-tests
> --disable-doc-gen --enable-gc
> 
> 1) Надо включить тесты (во всех пакетах, в которых тесты есть)
> 2) почему localstatedir=/nix/var ?

1) Тесты зависят от rapidcheck которого нет в репозиториях
2) Везде где nix есть нативным пакетом (Fedora, Arch и NiOS) localstatedir указывается как /nix/var решил последовать их примеру

(Ответ для Anton Farygin на комментарий #33)
> Пакет nix собран без учёта SharedLibsPolicy:
> https://packages.altlinux.org/ru/tasks/361634/

Вроде единственное нарушение policy это сборка %_libdir/*.so не в devel пакет, но только потому что эти библиотеки нужны самому nix и тогда получается что у него зависимость от devel пакета, что бы этого избежать положил библиотеки в него, могу положить их в пакет libnix это вроде policy не нарушает

(In reply to Boris Yumankulov from comment #41)
> (Ответ для Anton Farygin на комментарий #33)
> > Пакет nix собран без учёта SharedLibsPolicy:
> > https://packages.altlinux.org/ru/tasks/361634/
> 
> Вроде единственное нарушение policy это сборка %_libdir/*.so не в devel
> пакет, но только потому что эти библиотеки нужны самому nix и тогда
> получается что у него зависимость от devel пакета, что бы этого избежать
> положил библиотеки в него, могу положить их в пакет libnix это вроде policy
> не нарушает

Просьба попросить вашего ментора помочь разобраться с shared libs policy. Если вы не поняли, в чём проблема.

(In reply to Boris Yumankulov from comment #38)
> (Ответ для Anton Farygin на комментарий #32)
> > Из свежего:
> > https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/
> > 3148729581672545815
> > 
> > 1) При наличии апстримного гита схема сборки выбрана без его использования.
> > Этот вопрос ко всем собранным пакетам.
> 
> То что я собираю из тарболла разве влияет на работу пакета ? Кроме
> аппстримной истории которая по моему мнению только мешает я ничего не теряю.
> полиси на этот счёт так же отсутствует, так что переделывать пакета с
> тарболла на гит не вижу смысла

Апстримная история очень помогает качественно сопровождать пакет. Поэтому большая просьба при наличии апстримного гита - собирать с сохранением апстримной истории в пакете.


> 
> > 2) в секции files используется путь к файлу без макросов - зачем ?
> >  49 /usr/lib/systemd/system-generators/zram-generator
> 
> 
> По моему когда я собирал zram-generator макроса %_systemdgeneratordir не
> было, или я невнимательно смотрел, переделаю на макрос


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

Непонятно, почему ваш ментор заапрувил такой пакет.

(In reply to Boris Yumankulov from comment #40)
> (Ответ для Anton Farygin на комментарий #34)
> > %configure --localstatedir=/nix/var --disable-tests --disable-unit-tests
> > --disable-doc-gen --enable-gc
> > 
> > 1) Надо включить тесты (во всех пакетах, в которых тесты есть)
> > 2) почему localstatedir=/nix/var ?
> 
> 1) Тесты зависят от rapidcheck которого нет в репозиториях

Его можно упакетить ?

> 2) Везде где nix есть нативным пакетом (Fedora, Arch и NiOS) localstatedir
> указывается как /nix/var решил последовать их примеру

а в пакете каталога /nix/var нет.

(Ответ для Anton Farygin на комментарий #43)
> (In reply to Boris Yumankulov from comment #38)
> > (Ответ для Anton Farygin на комментарий #32)
> > > Из свежего:
> > > https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/
> > > 3148729581672545815
> > > 
> > > 1) При наличии апстримного гита схема сборки выбрана без его использования.
> > > Этот вопрос ко всем собранным пакетам.
> > 
> > То что я собираю из тарболла разве влияет на работу пакета ? Кроме
> > аппстримной истории которая по моему мнению только мешает я ничего не теряю.
> > полиси на этот счёт так же отсутствует, так что переделывать пакета с
> > тарболла на гит не вижу смысла
> 
> Апстримная история очень помогает качественно сопровождать пакет. Поэтому
Есть другая точка зрения — что апстримная история мешает сопровождать пакет, в частности, потому что апстримная история — о разработке, а в git пакета должна быть история пакета, а не разработки. Если же хочется сохранять историю апстрима для каких-то целей, это стоит делать отдельно, а не в пакете.
Также добавлю, что существует не так мало проектов, которые релизы выпускают в виде тарболов, а содержимое git не подходит для прямой сборки без особых ухищрений.
Поэтому, при всём уважении к другому мнению — оно остаётся другим мнением, и не ясно, почему нужно всех с ним продавливать.

> большая просьба при наличии апстримного гита - собирать с сохранением
> апстримной истории в пакете.
> 


...
> Даже если нет макроса с полным путём, макрос для каталогов более верхнего
> уровня есть всегда.
> 
> Непонятно, почему ваш ментор заапрувил такой пакет.
Я могу объяснить.
1. Потому что у нас нет ресурса, где написано, какие макросы стоит использовать и для чего. Есть безнадёжно устаревшая страница https://www.altlinux.org/Spec/Предопределенные_макросы
2. Потому что чрезмерное увлечение макросами к хорошему не приводит, нужно знать и понимать границы. А с ними проблема — см. пункт 1.

(In reply to Vitaly Lipatov from comment #45)
> (Ответ для Anton Farygin на комментарий #43)
> > (In reply to Boris Yumankulov from comment #38)
> > > (Ответ для Anton Farygin на комментарий #32)
> > > > Из свежего:
> > > > https://packages.altlinux.org/ru/sisyphus/srpms/zram-generator/
> > > > 3148729581672545815
> > > > 
> > > > 1) При наличии апстримного гита схема сборки выбрана без его использования.
> > > > Этот вопрос ко всем собранным пакетам.
> > > 
> > > То что я собираю из тарболла разве влияет на работу пакета ? Кроме
> > > аппстримной истории которая по моему мнению только мешает я ничего не теряю.
> > > полиси на этот счёт так же отсутствует, так что переделывать пакета с
> > > тарболла на гит не вижу смысла
> > 
> > Апстримная история очень помогает качественно сопровождать пакет. Поэтому
> Есть другая точка зрения — что апстримная история мешает сопровождать пакет,
> в частности, потому что апстримная история — о разработке, а в git пакета
> должна быть история пакета, а не разработки. Если же хочется сохранять
> историю апстрима для каких-то целей, это стоит делать отдельно, а не в
> пакете.
> Также добавлю, что существует не так мало проектов, которые релизы выпускают
> в виде тарболов, а содержимое git не подходит для прямой сборки без особых
> ухищрений.
> Поэтому, при всём уважении к другому мнению — оно остаётся другим мнением, и
> не ясно, почему нужно всех с ним продавливать.

Один из самых главных навыков самостоятельного мантейнера - уметь аргументированно отстаивать свою точку зрения. У меня нет сомнений в том, что этот навык есть у ментора, но мы же готовим нового самостоятельного мантейнера.

Поддерживаю Диму.
Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор убедил о единственно-правильном решении.

Что касается макросов - вопрос был именно к ментору. Выглядит так, что ментор вообще не понимает смысла использования макросов.

Очень жаль.

(In reply to Anton Farygin from comment #47)
> Поддерживаю Диму.
> Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор
> убедил о единственно-правильном решении.
> 
> Что касается макросов - вопрос был именно к ментору. Выглядит так, что
> ментор вообще не понимает смысла использования макросов.
> 
> Очень жаль.

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

(Ответ для Anton Farygin на комментарий #44)
> (In reply to Boris Yumankulov from comment #40)
> > (Ответ для Anton Farygin на комментарий #34)
> > > %configure --localstatedir=/nix/var --disable-tests --disable-unit-tests
> > > --disable-doc-gen --enable-gc
> > > 
> > > 1) Надо включить тесты (во всех пакетах, в которых тесты есть)
> > > 2) почему localstatedir=/nix/var ?
> > 
> > 1) Тесты зависят от rapidcheck которого нет в репозиториях
> 
> Его можно упакетить ?

Из гита да, так как у пакета отсутствуют релизы

> > 2) Везде где nix есть нативным пакетом (Fedora, Arch и NiOS) localstatedir
> > указывается как /nix/var решил последовать их примеру
> 
> а в пакете каталога /nix/var нет.

Потому что он появляется после добавления репозитория

nix-channel --add https://nixos.org/channels/nixpkgs-unstable
nix-channel --update

Можно упаковать в пакет пустые папки и файлы как это делается здесь

https://download.copr.fedorainfracloud.org/results/petersen/nix/fedora-41-ppc64le/08039673-nix/nix.spec

(In reply to Boris Yumankulov from comment #49)
> 
> Можно упаковать в пакет пустые папки и файлы как это делается здесь
> 
> https://download.copr.fedorainfracloud.org/results/petersen/nix/fedora-41-
> ppc64le/08039673-nix/nix.spec

Да, так и надо делать - после удаления пакета не должно оставаться мусора.

(In reply to Boris Yumankulov from comment #48)
> (In reply to Anton Farygin from comment #47)
> > Поддерживаю Диму.
> > Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор
> > убедил о единственно-правильном решении.
> > 
> > Что касается макросов - вопрос был именно к ментору. Выглядит так, что
> > ментор вообще не понимает смысла использования макросов.
> > 
> > Очень жаль.
> 
> Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и
> историю пакета не стоит, подобное наоборот усложняет сопровождение, когда я
> захожу в свой репозиторий я хочу видеть только свои коммиты, если мне нужен
> будет аппстрим я пойду в аппстрим, и в тои что это единственно верный способ
> сопровождения пакетов меня никто не убеждал, я просто сопровождаю так как
> удобно для меня

Но вы не один ментейнер в репозитории и наличие апстримной истории сильно облегчает процесс поиска ошибок между релизами.

Если вы принципиально планируете использовать эту схему для упаковки, то секретарю придётся поискать другого ревьювера - я не готов аппрувить задания, у которых есть апстримный гит и он не используется в полной мере для сопровождения пакетов.

(Ответ для Anton Farygin на комментарий #47)
...
> Что касается макросов - вопрос был именно к ментору. Выглядит так, что
> ментор вообще не понимает смысла использования макросов.
> 
> Очень жаль.
Если что, это я 19 лет назад сделал пакет rpm-build-altlinux-compat, который делал возможным бэкпортирование пакетов, затруднённое неторопливым или отсутствующим переносом новых макросов на стабильные бранчи.
И это я сделал rpm-build-compat, который обеспечивает базовые rpm/альтовые макросы на всех существующих системах, не обязательно основанных на rpm, включая FreeBSD.
И я отлично понимаю, насколько макросы нужны, а где ими начали чрезмерно увлекаться, затрудняя вхождение новых мантейнеров (они должны строить у себя в голове таблицу соответствий путь<->макрос), не предоставляя актуального инструмента для перевода путей в макросы.
Если сборочные скрипты думают одно, а в макросах другое, ничем тут макросы не помогут, всё равно сборка развалится. Это было красиво только для configure. Ну и для нормальных cmake-файлов (которые — редкость).
Представление некоторых разработчиках о макросах достаточно устарело, вот и всё.

(Ответ для Anton Farygin на комментарий #51)
> (In reply to Boris Yumankulov from comment #48)
> > (In reply to Anton Farygin from comment #47)
> > > Поддерживаю Диму.
> > > Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор
> > > убедил о единственно-правильном решении.
> > > 
> > > Что касается макросов - вопрос был именно к ментору. Выглядит так, что
> > > ментор вообще не понимает смысла использования макросов.
> > > 
> > > Очень жаль.
> > 
> > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и
> > историю пакета не стоит, подобное наоборот усложняет сопровождение, когда я
> > захожу в свой репозиторий я хочу видеть только свои коммиты, если мне нужен
> > будет аппстрим я пойду в аппстрим, и в тои что это единственно верный способ
> > сопровождения пакетов меня никто не убеждал, я просто сопровождаю так как
> > удобно для меня
> 
> Но вы не один ментейнер в репозитории и наличие апстримной истории сильно
> облегчает процесс поиска ошибок между релизами.
> 
> Если вы принципиально планируете использовать эту схему для упаковки, то
> секретарю придётся поискать другого ревьювера - я не готов аппрувить
> задания, у которых есть апстримный гит и он не используется в полной мере
> для сопровождения пакетов.
Прошу также отметить, что этот ревьювер всем навязывает свою схему сборки, вынуждая прогибаться под его требования, чтобы хоть как-то за пару лет пройти джойн. Сейчас появилась гибкость — единственный ревьювер вообще отказывается.

Но добавлю, что ревьювера никто и не просит аппрувить задания. У него другая задача, как мне казалось.

(In reply to Vitaly Lipatov from comment #53)
> (Ответ для Anton Farygin на комментарий #51)
> > (In reply to Boris Yumankulov from comment #48)
> > > (In reply to Anton Farygin from comment #47)
> > > > Поддерживаю Диму.
> > > > Я знаю мнение ментора, мне важно услышать ментейнера, которого видимо ментор
> > > > убедил о единственно-правильном решении.
> > > > 
> > > > Что касается макросов - вопрос был именно к ментору. Выглядит так, что
> > > > ментор вообще не понимает смысла использования макросов.
> > > > 
> > > > Очень жаль.
> > > 
> > > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и
> > > историю пакета не стоит, подобное наоборот усложняет сопровождение, когда я
> > > захожу в свой репозиторий я хочу видеть только свои коммиты, если мне нужен
> > > будет аппстрим я пойду в аппстрим, и в тои что это единственно верный способ
> > > сопровождения пакетов меня никто не убеждал, я просто сопровождаю так как
> > > удобно для меня
> > 
> > Но вы не один ментейнер в репозитории и наличие апстримной истории сильно
> > облегчает процесс поиска ошибок между релизами.
> > 
> > Если вы принципиально планируете использовать эту схему для упаковки, то
> > секретарю придётся поискать другого ревьювера - я не готов аппрувить
> > задания, у которых есть апстримный гит и он не используется в полной мере
> > для сопровождения пакетов.
> Прошу также отметить, что этот ревьювер всем навязывает свою схему сборки,
> вынуждая прогибаться под его требования, чтобы хоть как-то за пару лет
> пройти джойн. Сейчас появилась гибкость — единственный ревьювер вообще
> отказывается.

Ревью дело добровольное. Я ещё хочу предложить дать право тому, кто ревьювил - отзывать ревью. Потому что уже неоднократно было мной замечено, как нормально обученный кандидат начинает опять скатываться в сборку пакетов "как Виталий советует".


> 
> Но добавлю, что ревьювера никто и не просит аппрувить задания. У него другая
> задача, как мне казалось.

Старых не исправить, новых надо учить сразу делать хорошо. Всё просто.

У нас ещё осталась возможность собирать из src.rpm и мы даже иногда ей пользуемся, но собирать все пакеты таким образом новому кандидату точно не стоит. 
Ровно такая же история с отказом от импорта гита. Я добавлю, что импорт апстримной истории помимо всех основных преимуществ создаёт ещё одно зеркало апстримной истории.

Мне кажется что этот тикет не очень удачное место для данной дискуссии.

(Ответ для Anton Farygin на комментарий #54)
...
> Ревью дело добровольное. Я ещё хочу предложить дать право тому, кто ревьювил
> - отзывать ревью. Потому что уже неоднократно было мной замечено, как
> нормально обученный кандидат начинает опять скатываться в сборку пакетов
> "как Виталий советует".
Это фантазии, я никому не советую. И рассказываю, что есть два варианта. И что надо уметь собирать обоими способами. Просто я не навязываю своё мнение и не заставляю под страхом не пройти джойн делать как мне хочется.
Нормально обученный кандидат — это тоже фантазии. Когда возникают нелепые формальные требования, возникают и способы приспособится к этому и сделать как требует преподаватель, потому что зачёт надо получить, а не тараканов ловить.

Я ещё хочу предложить выбирать ревьюверов, а то ревью такое добровольное, что его кто-то тайный назначает, как судью в РФ.

> > 
> > Но добавлю, что ревьювера никто и не просит аппрувить задания. У него другая
> > задача, как мне казалось.
> 
> Старых не исправить, новых надо учить сразу делать хорошо. Всё просто.
> 
> У нас ещё осталась возможность собирать из src.rpm и мы даже иногда ей
> пользуемся, но собирать все пакеты таким образом новому кандидату точно не
> стоит. 
Это уход в крайность.

> Ровно такая же история с отказом от импорта гита. Я добавлю, что импорт
Да не с отказом от импорта гита. А с принуждением импортировать гит.

> апстримной истории помимо всех основных преимуществ создаёт ещё одно зеркало
> апстримной истории.
А точно создание зеркала апстримной истории это задача мантейнера? У нас тут не разработка софта, а сопровождение.

> Мне кажется что этот тикет не очень удачное место для данной дискуссии.
Ну не я начал вопросы и упрёки к ментору.

(In reply to Boris Yumankulov from comment #48)
> Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и
> историю пакета не стоит, подобное наоборот усложняет сопровождение,

Расскажите, пожалуйста, в чём именно для вас проявляется усложнение сопровождения.

> когда я захожу в свой репозиторий я хочу видеть только свои коммиты,

Расскажите, пожалуйста, каким образом апстримные коммиты мешают именно вам?

> если мне нужен будет аппстрим я пойду в аппстрим,

Окей, допустим.  А если вам понадобятся и те, и другие коммиты, вы будете переключаться между двумя репозиториями?

(In reply to Vitaly Lipatov from comment #55)
> (Ответ для Anton Farygin на комментарий #54)
> > апстримной истории помимо всех основных преимуществ создаёт ещё одно зеркало
> > апстримной истории.
> А точно создание зеркала апстримной истории это задача мантейнера? У нас тут
> не разработка софта, а сопровождение.

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

Я очень надеюсь что к нам будут приходить в команду люди, не разделяющие это мнение. Качественно сопровождать софт можно только принимая участия в разработке, чем мы с тобой к сожалению не занимаемся (просто потому что упакечивать приходится слишком много пакетов и это точно не позволяет нам принимать участие в разработке).

Не занимаясь (не принимая участия) апстримной разработкой невозможно разгребать то множество ошибок, которое сыпется на ментейнера по функционированию собираемого софта.

Ну и кстати, уж коль ты всё-таки решил продолжить в этом тикете: что делать с менторами, которые сами нарушают Policy ? Я сейчас про вот это Policy:
https://www.altlinux.org/Vulnerability_Policy

И ещё почему-то так сложилось что только кандидаты, ментором которых является lav@ сопротивляются схеме ведения пакетов с апстримной историей гита, все остальные после объяснения переходят на неё и спокойно без проблем сопровождают пакеты с использованием этой схемы ?

(In reply to Dmitry V. Levin from comment #56)
> (In reply to Boris Yumankulov from comment #48)
> > Моё мнение абсолютно такое же, смешивать в кучу аппстримную историю и
> > историю пакета не стоит, подобное наоборот усложняет сопровождение,
> 
> Расскажите, пожалуйста, в чём именно для вас проявляется усложнение
> сопровождения.
> 
> > когда я захожу в свой репозиторий я хочу видеть только свои коммиты,
> 
> Расскажите, пожалуйста, каким образом апстримные коммиты мешают именно вам?
> 
> > если мне нужен будет аппстрим я пойду в аппстрим,
> 
> Окей, допустим.  А если вам понадобятся и те, и другие коммиты, вы будете
> переключаться между двумя репозиториями?

Да, я так и делаю и всегда делал при сопровождение пакетов для Arch Linux и Fedora Linux, полагаю отсюда привычка собирать из тарбола, я просто собираю так как привык собирать в других дистрибутивах, потому что лично для себя я не вижу преимуществ сборки с гита, что касается аргумента на счёт того что я не один и должен собирать так как удобно другим, я так не считаю, пока я мейнтейнер пакета я имею полное право собирать как удобно и привычно мне, а если мейнтейнер сменится пусть сам и переделывает как ему будет удобно

Нести в Альт Линукс практику сборки из других дистрибутивов - очень плохая идея. Тут свои сложившиеся традиции и в рамках JOIN лучше перенять их.

(Ответ для Anton Farygin на комментарий #59)
> Нести в Альт Линукс практику сборки из других дистрибутивов - очень плохая
> идея. Тут свои сложившиеся традиции и в рамках JOIN лучше перенять их.

В который раз спрашиваю разве сборка с тарбола вместо гита является ошибкой ? Пакет из тарбола хуже работает, у него проблемы с зависимостями, или ещё что ? Я не несу практику сборки из других дистрибутивов в Альт и стараюсь соблюдать policy, но собирать с гита не собираюсь принципиально, если вы настаиваете на сборке с гита то думаю стоит найти нового ревьювера

Я с этого и начал.

@glebfm - у меня освободился ещё один слот

Будут ли какие либо сподвижки ? Уже достаточно много прошло и список собранных мной пакетов успел несколько раз сменится, а join всё не продвигается

(In reply to Boris Yumankulov from comment #62)
> Будут ли какие либо сподвижки ? Уже достаточно много прошло и список
> собранных мной пакетов успел несколько раз сменится, а join всё не
> продвигается
Баг находится в статусе 3.6 (по новой процедуре это сейчас 3.7), т.е. ожидание решения ментора.

4.0

Считаю, что давно Борис готов отправлять пакеты в Сизиф самостоятельно.

Спустя ~два месяца вновь никакого движения, процесс нужно сделать более прозрачным что бы кандидаты видели чего ждут, поиск рецензента например или что-то ещё