49104 2024-01-17 18:02:05 +0300 Кто такой "сопровождающий"? 2025-12-27 20:17:35 +0300 1 1 2 Infrastructure Infrastructure packages.altlinux.org unspecified x86 Linux NEW P5 normal --- 41023 1 grenka dshein glebfm iv ldv rider ytinka7 cas oldest_to_newest 240286 0 grenka 2024-01-17 18:02:05 +0300 С давних пор, ещё на сайте sisyphus.ru сайт выводил топ мейнтейнеров (или как нынче модно говорить по-славянски сопровождающих). Сейчас эту функцию давно уже убрали, хоть и было бы интересно посмотреть кто пакетирует как пчела. Короче я накидал скриптик на python, который сортирует это безобразие и у меня возникли вопросы к количеству "своих" пакетов. Представьте моё удивление, когда я открыл https://packages.altlinux.org/ru/sisyphus/srpms/boost А там я мейнтейнер. Какого лешего спрашивается? Иван Мельников обновляет этот пакет в поте лица, я сделал маленькое NMU и теперь сопровождающий? Предлагаю пересмотреть алгоритмы вычисления сопровождающих. Такой результат корректным ни в каком приближении назвать нельзя. 240287 1 dshein 2024-01-17 18:07:38 +0300 Всё упирается в решение вопроса о том, кого и по какому признаку считать сопровождающим: https://bugzilla.altlinux.org/41023 https://bugzilla.altlinux.org/41942 240290 2 grenka 2024-01-17 18:46:14 +0300 "А сопровождающего пакет можно вычислить по changelog, используя для этого не очень сложную формулу." (с) rider@ https://bugzilla.altlinux.org/show_bug.cgi?id=41023#c2 Если задачу не могут решить уже несколько лет, имеет смысл попробовать разбить её на простые подзадачи: 1.) Найти бедолагу, ответственного за решение задачи 2.) Почистить мейнтейнеров, которые больше не мейтейнеры 3.) Опционально: роботом убрать поле Packager во всех пакетах, если это так уж необходимо 4.) Написать "не очень сложную" формулу 5.) ??????? 6.) PROFIT! По-хорошему после процедуры провести синхронизацию полученного списка со списком acl. Или даже наоборот, сначала сделать список acl, основываясь на частоте вносимых изменений и их актуальности, а уже из него лидеров ацл назначить сопровождающими. 240295 3 rider 2024-01-18 08:53:17 +0300 Давайте для начала в параллельных задачах придём к консолидированному мнению - кто и как должен считаться сопровождающим пакета. А дальше уже будет всё остальное. Т.к. консолидированного мнения нет, то сейчас используется старая схема с Packager, а в интерфейсах просмотра пакетов приходится городить разные фильтры: https://packages.altlinux.org/en/p10/maintainers/grenka/srpms?by_acl=nick_group 240296 4 rider 2024-01-18 08:54:52 +0300 Что касается чистки ментейнеров, которые уже не ментейнеры - нужно везде активно удалять поле Packager, заполенненое неправильно. И приводить в порядок acl на пакеты. Мне кажется, что тут нужно услышать какое-то мнение от Димы. 240360 5 grenka 2024-01-19 13:36:19 +0300 В мире айти всё довольно быстро движется вперёд. Поэтому начальной проверкой алгоритма пусть будет: * обновлялся ли пакет за последние N лет? (допустим N=5) - нет - nobody@ - да - идём далее Берём записи ченджлога за последние N лет (либо последние M=15 записей) и создаём два списка авторов изменений за вычетом записей содержащих NMU. В одном списке авторы делавшие релизы alt0* и alt1 - то есть авторы "обновлений", во втором авторы всех остальных изменений "патчи, фиксы и т.п.". Рядом с каждым ником ставим в соответствие количество таких записей и сортируем оба списка по убыванию. Естественно делаем джойн по нику и если он существует в двух списках, то переносим его труды из изменений в обновления. * лидер пакета - человек с наибольшим числом из этих двух списков. Если этот человек из списка "фиксеров", вторым в ацл идёт первый из списка "обновлявших", дальше в порядке убывания до K=3. Естественно приоритет за людьми из списка "обновлявших". Понятное дело, что переменные N, M, K можно выбрать свои. Не претендую на истинность, но это можно обсудить с контрпримерами, где этот алгоритм сработает не так, как хотелось бы и вместе конструктивно доработать! 240363 6 grenka 2024-01-19 13:38:49 +0300 не "либо последние M=15", а "не более последних М=15" 279695 7 rider 2025-12-27 20:09:08 +0300 предлагаю такой алгоритм определения основного мейнтейнера пакета Алгоритм анализирует историю изменений пакета (changelog) и данные из Bugzilla, чтобы определить, кто является наиболее активным мейнтейнером. Учитываемые факторы: 1. Обновления версий (alt1, 0.x) - самый весомый вклад, показывает, что человек следит за upstream и обновляет пакет до новых версий. 2. Патчи и исправления (alt2, alt3 и т.д.) - менее весомый вклад, но тоже учитывается. 3. Исправления багов из Bugzilla - учитываются закрытые баги со статусом FIXED, где человек указан как assignee. 4. NMU (Non-Maintainer Upload) - загрузки от людей не из ACL пакета с пометкой о NMU не учитываются, чтобы случайные контрибьюторы не становились ментейнерами Особенности подсчета: - Старые изменения постепенно теряют вес. Период полураспада - 2 года. То есть изменение двухлетней давности весит в 2 раза меньше, чем сегодняшнее. - Если человек не в ACL пакета, его вклад учитывается с коэффициентом 0.5. - Бонус за активность: если мейнтейнер сделал последний коммит в пакет И при этом имеет недавнюю активность (хотя бы 1 багфикс или 3+ коммита за последние 6 месяцев), его итоговый балл умножается на 2.5. Это позволяет текущему активному мейнтейнеру обойти людей с большой историей, но без недавней активности. Определение статуса пакета: - active - у лучшего мейнтейнера балл >= 1.0 - low_activity - балл от 0.3 до 1.0 - orphaned - балл < 0.3 Реализацию сделаю на rdb.altlinux.org, можно будет посмотреть и поиграть с коэффициэнтами 279696 8 rider 2025-12-27 20:17:35 +0300 https://altlinux.space/ALTLinux/altrepoapi/pulls/185 Настройки алгоритма вынес в отдельный файл, можно поиграться с ними будет потом.